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
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Tkay
April 11, 2024
Technology
1.8k
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.2k
Splunk Experience Day 2025 - Splunk Federated Search for S3 ✕ AWS連携
sakaitakeshi
0
750
セキュリティ運用って包括的にできていますか?SaaSを使って次のステップへ / Comprehensive Cyber Security Operations for Cloud Services Using SaaS
sakaitakeshi
0
1.1k
Showcase2023_進化し続けるサイバーセキュリティ脅威を防ぐSaaSソリューション.pdf
sakaitakeshi
0
2.1k
Akiba-dot-SaaS-ExtraHop
sakaitakeshi
1
790
AKIBA-dot-SaaS-Cloudflare-ZeroTrust
sakaitakeshi
0
1.2k
Other Decks in Technology
See All in Technology
Baseline対応のDOMの型定義を作った
uhyo
3
730
AWS Blocks を触ってみた/first-tach-aws-blocks
fossamagna
2
150
金融の未来を考える / Thinking About the Future of Finance
ks91
PRO
0
180
地域 SRE コミュニティ最前線 / SRE NEXT 2026 Discussion Night Track C
muziyoshiz
0
190
FinOps X 2026 Recap from Engineer Side #JapanFinOps
chacco38
0
270
SRE依存からの脱却 運用を開 発チームへ移す、 フルサイ クル開 発体制の実践
joooee0000
0
2.4k
DatabricksにおけるMCPソリューション
taka_aki
1
160
なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren't really working
vtryo
3
3.3k
[2026-07-15] AI Ready なはずだったアーキテクチャと、見えてきた課題・次に目指す状態
wxyzzz
3
1.2k
product engineering with qa
nealle
0
160
プライバシー保護の理論と実践
lycorptech_jp
PRO
1
250
美しいコードを書くためにF#を学んでみた話
yud0uhu
1
390
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Facilitating Awesome Meetings
lara
57
7k
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.7k
Deep Space Network (abreviated)
tonyrice
0
220
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
220
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.7k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
260
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
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