インシデントレスポンス のライフサイクルを 廻すポイントってなに？ ~ インシデントレスポンスで組織のセキュリティを 底上げ しよう ~ 1

2 ⾃⼰紹介 酒井 剛（Takeshi Sakai） ● アライアンス事業部 テックG ● セキュリティ系SaaS製品 Sumo Logic、Cloudflare Zero Trust ● 2022年4⽉⼊社 ● 前職では、EDR/CloudSWG導⼊、CSIRT ● Nagios/Cacti、インフラエンジニア ● 趣味：ケーキ作り(前前職パティシエ) 、キャンプ ● 本⽇のスイーツ：タルト‧マルグリット            （仏語 マーガレットの意、お花のタルト）

3 アジェンダ ● なぜ、インシデントレスポンスなのか？ ● インシデントレスポンスを実施していくうえでのポイント ココ

4 （サイバー）セキュリティ対策って どんなことやっていますか？ セキュリティについて悩んでいる。。。

5 セキュリティについて悩んでいる。。。 資産管理 認証 アクセス制御 脆弱性対策 マルウェア対策 （アンチウィルス製品） 経路の暗号化 データの暗号化 ネットワークのセグメント ⼈的ミスへの対応 セキュリティポリシーの策定

6 セキュリティにおける予防と発⾒ セキュリティの考え⽅は⼤きく分けて２種類 予防   と   発⾒

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、詐欺サイト） ● ゼロデイ脆弱性をついた攻撃 予防だけで完全に防ぐことは不可能 侵⼊を前提に対策をとる必要がある 理由１

12 なぜ？インシデントレンスポンス？ インシデントレスポンスとは？ ● インシデントを早期に特定し、ビジネス損失が発⽣する前に防ぐ ● インシデント発⽣後に、素早く回復し、ビジネス損失を可能な限 り⼩さくする ● 発⽣したインシデントを振り返り、修正する（適切な予防処置、 検出メカニズム） 継続してセキュリティを運⽤することで 組織のセキュリティを底上げする 理由２

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