インシデントレスポンスのライフサイクルを廻すポイントってなに / Pinpoints of Incidentresponse Lifecycle for Operation

1. インシデントレスポンス のライフサイクルを 廻すポイントってなに？ ~ インシデントレスポンスで組織のセキュリティを 底上げ しよう ~ 1
2. 2 ⾃⼰紹介 酒井 剛（Takeshi Sakai） • アライアンス事業部 テックG • セキュリティ系SaaS製品 Sumo Logic、Cloudflare Zero Trust • 2022年4⽉⼊社 • 前職では、EDR/CloudSWG導⼊、CSIRT • Nagios/Cacti、インフラエンジニア • 趣味：ケーキ作り(前前職パティシエ) 、キャンプ • 本⽇のスイーツ：タルト‧マルグリット            （仏語 マーガレットの意、お花のタルト）
3. 3 アジェンダ • なぜ、インシデントレスポンスなのか？ • インシデントレスポンスを実施していくうえでのポイント ココ
4. 4 （サイバー）セキュリティ対策って どんなことやっていますか？ セキュリティについて悩んでいる。。。
5. 5 セキュリティについて悩んでいる。。。 資産管理 認証 アクセス制御 脆弱性対策 マルウェア対策 （アンチウィルス製品） 経路の暗号化 データの暗号化 ネットワークのセグメント ⼈的ミスへの対応 セキュリティポリシーの策定
6. 6 セキュリティにおける予防と発⾒ セキュリティの考え⽅は⼤きく分けて２種類 予防   と   発⾒
7. 7 セキュリティにおける予防と発⾒ ＝ 攻撃者が侵⼊する前に未然に防ぐ、ビジネスへの   悪影響（リスク）が起こらないようにするための   取り組み ＝ 侵⼊が発⽣した場合に検知し、閉じ込め、取り除   き、元の状態へ戻すための取り組み 予防的対策 発⾒的対策
8. 識別 ID 防御 PR 検知 DE 対応 RS 復旧 RC セキュリティフレームワークから⾒る全体像 8 未然に防ぐことを中⼼に考えられている 侵⼊後の検知‧対応‧復旧にも着眼点を置いている 予防的対策 発⾒的対策 ISO 27001 NIST CSF1.1 ※NIST CSF2.0では新たに統治 (Govern) が増えている = インシデントレスポンス
9. 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. 10 なぜ？インシデントレンスポンス？ ニューノーマルな時代 • インターネットサービス利⽤の拡⼤ （パブリッククラウドサービス、リモートワーク、オンライン会議） • 攻撃者の標的はインターネットへ→攻撃対象の拡⼤と防御側の複雑化 攻撃の⾼度化（Advanced Percistent Threat） • フィッシング攻撃 （MFA疲労、宅配業者を装うSMS、詐欺サイト） • ゼロデイ脆弱性をついた攻撃
11. 11 なぜ？インシデントレンスポンス？ ニューノーマルな時代 • インターネットサービス利⽤の拡⼤ （パブリッククラウドサービス、リモートワーク、オンライン会議） • 攻撃者の標的はインターネットへ→攻撃対象の拡⼤と防御側の複雑化 攻撃の⾼度化（Advanced Percistent Threat） • フィッシング攻撃 （MFA疲労、宅配業者を装うSMS、詐欺サイト） • ゼロデイ脆弱性をついた攻撃 予防だけで完全に防ぐことは不可能 侵⼊を前提に対策をとる必要がある 理由１
12. 12 なぜ？インシデントレンスポンス？ インシデントレスポンスとは？ • インシデントを早期に特定し、ビジネス損失が発⽣する前に防ぐ • インシデント発⽣後に、素早く回復し、ビジネス損失を可能な限 り⼩さくする • 発⽣したインシデントを振り返り、修正する（適切な予防処置、 検出メカニズム） 継続してセキュリティを運⽤することで 組織のセキュリティを底上げする 理由２
13. 13 アジェンダ • なぜ、インシデントレスポンスなのか？ • インシデントレスポンスを実施していくうえでのポイント ココ
14. NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 14 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備 Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
15. 15 ライフサイクルを廻すポイント 準備段階が⾮常に重要 準備がおろそかだと     おいしいケーキは作れない
16. NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 16 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備 Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
17. 17 So, what? （何を準備するのか？） PPT People Process Technology = （⼈  プロセス   技術） を準備する
18. 18 People（⼈）を準備する • 継続的な⼈材育成 ◦ セキュリティの資格を取る（AWSなら SCS-C02） ◦ 侵⼊後を想定した、シミュレーションやワークショップを通じて継 続的に教育を実施
19. 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. 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. 21 People（⼈）を準備する 痛みのピラミッド http://detect-respond.blogspot.com/2013/03/ the-pyramid-of-pain.html 攻撃⼿法は簡単に変えれない
22. 22 Process（プロセス）を準備する • プロセスモデルを採⽤する ◦ 例：NIST インシデント対応サイクル、SANS PICERLモデル • インシデント対応計画やプレイブックを作成する ◦ インシデント対応フローの作成 ◦ トリアージ（インシデントの優先度）と対応⽅針 ◦ 想定されるインシデントの調査⽅法や軽減策
23. 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. 24 Process（プロセス）を準備する • プロセスモデルを採⽤する ◦ 例：NIST インシデント対応サイクル、SANS PICERLモデル • インシデント対応計画やプレイブックを作成する ◦ インシデント対応フローの作成 ◦ トリアージ（インシデントの優先度）と対応⽅針 ◦ 想定されるインシデントの調査⽅法や軽減策
25. 25 インシデント対応フローの作成（例） • JP CERT/CC インシデントハンドリング マニュアル ◦ インシデント発⽣から収束までの共 通フローを作成する ◦ ステークホルダー、コミュニケー ションパス ◦ 各イベントの発⽣タイミング https://www.jpcert.or.jp/csirt_material/operation_phase.html Process（プロセス）を準備する
26. 26 トリアージ（インシデントの優先度）と対応⽅針 Process（プロセス）を準備する 重大度 判断例 対応方針 重大 取引先、顧客、ユーザーなど影響が広範囲。 機密情報が持ち出されている、公開サー バーが乗っ取られている 直ちにエスカレーション、関連部署と連 携、社外公表 高 マルウェア感染、不審な通信が断続的に継 続 直ちにエスカレーション、関連部署と連携 中 マルウェア感染の疑い、通信は NW機器で遮 断されていて限定的 インシデント対応チーム内で対応、エスカ レーション、月次レポート等で共有 低 マルウェア感染前に駆除、脅威の未然防止、 スキャン行為のみ、外からの通信遮断できて いるなど インシデント対応チーム内で対応、エスカ レーション無し、月次レポート等で共有
27. 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. 28 Technology（技術）を準備する • 分析‧アラートのためのログを準備する ◦ ここで準備できていないログ以外には、侵⼊後の⾏動に関する可視 性は無くなる。必要ないログは取る必要はないが、必要なログは何 かを定義し、設定しておく。⇒ ログは真実の源 • デジタルフォレンジック ◦ 証跡（ログ、スナップショット、物理ハードディスク）の保全 ◦ アウトソースが可能なよう準備しておく
29. 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. 30 • 分析‧アラートのためのログを準備する ◦ ここで準備できていないログ以外には、侵⼊後の⾏動に関する可視 性は無くなる。必要ないログは取る必要はないが、必要なログは何 かを定義し、設定しておく。 • デジタルフォレンジック ◦ 証跡（ログ、スナップショット、物理ハードディスク）の保全 ◦ アウトソースが可能なよう準備しておく Technology（技術）を準備する
31. NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 31 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備 Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
32. NIST SP 800-61 (IPA ⽇本語訳 https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/000025341.pdf) 32 インシデントレスポンスのライフサイクルと運⽤ Phase1 準備 Phase2 検知‧分析 Phase3 隔離‧根絶‧回復 Phase4 事後分析
33. 33 事後分析 • 発⽣したインシデントのレビューを開催 ◦ 関係するステークホルダーを招集する ◦ インシデントに気付いたのはどの時点だったか ◦ インシデントのアラートを発⽣させたのは何か ◦ インシデント対応の中で機能したものは何か、しなかったものは何か ◦ インシデント識別にかかる時間を短縮するために何が有効か ◦ インシデント再発を防ぐ予防策はあるか ◦ 対策を⾏うためにどの程度時間が必要か、プランを⽴てる ⼈‧プロセス‧技術 の何を改善する必要があったのか （レビューをもとに準備や予防対策へ）
34. 34 まとめ • 予防的対策＋発⾒的対策 ◦ 予防だけでは防げない、侵⼊を前提としたセキュリティを • ライフサイクルは準備が⼤事 ◦ ⼈‧プロセス‧技術 • ログは真実の源 ◦ 必要なログを選択、適切なツールを使って分析を • 事後分析もしっかり、セキュリティ全体を底上げする