[前回] AWS公式資料で挑むSCS認定(13)-Cognito
はじめに
引き続き「Security, Identity & Compliance」サービスシリーズです。
Amazon Detectiveは、セキュリティデータを分析、視覚化し、
潜在的なセキュリティ問題の根本原因を迅速に特定するためのサービスらしいです。
教材を選ぶ
AWS Black Belt Online Seminar の Amazon Detective 資料を勉強に使用します。
インシデント発生時、Amzon Detectiveサービスを駆使し、
攻撃者の進入経路を分析する調査例が、臨場感あり面白かったです。
セキュリティインシデントとは
- 組織が定めるセキュリティポリシーやコンピューターの利用規定に対する違反行為または差し迫った脅威
- 標準的なセキュリティ活動に対する違反行為または差し迫った脅威
セキュリティインシデントの例
- サービス妨害
- 悪意のコード
- 不正アクセス
- 不適切な使用
セキュリティインシデント対応が重要な理由
攻撃により個人データや業務データが頻繁に損なわれている状況下で、
インシデント対応を適切に実施すると、
- 迅速かつ効率的にセキュリティインシデントから復旧するのを助ける
- 情報の損失や盗難、サービスの中断を最小限に抑えることができる
- 事件処理の際に得た情報を使って、将来の事件に備え、システムとデータを強力に防護
- 事件に伴って発生する可能性がある法的な問題を正しく扱える
AWS サービスとセキュリティインシデント対応
AWSセキュリティ戦略が、どのようにAWSサービス群により実現されているか、
その全体像「森」をわかりやすく示してくれた貴重な一枚。
引用元: https://d1.awsstatic.com/webinars/jp/pdf/services/20200715_AWSBlackBelt2020_AmazonDetective.pdf
セキュリティ調査プロセス
- インシデントに関連したテラバイト規模のログを収集
- ETL ツールやカスタムスクリプトで、ログを分析できる状態に変換
- ツール等を利用してデータを視覚化して分析
- クエリ文を作成して詳細に事象を解析後、結論づけ
セキュリティ調査の課題
- 大量のノイズ
- アラートの大部分はインシデントとは関係ないデータ
- 複雑さ
- システムの拡大と変化が早く、情報更新が追い付かず、インシデントを適切に判断することが困難
- 人材とスキル不足
- 熟練した技術力のあるセキュリティエンジニアの不足
- セキュリティ対策コスト
- 外部のサービス利用、または内部で体制作り、どちらもコストが高い
Amazon Detective の特徴
- ログの自動収集
- 分析の自動化
- 視覚化
ユーザにとってのメリット
- より迅速で効果的な調査
- 情報を一ヶ所に集めて、統一的な画面からインタラクティブに調査
- 通常値と異常値の表示、時系列の変化、影響を受けたリソースや関連する情報へのドリルダウン等で迅速に調査可能
- 継続的なデータ更新で時間と労力を節約
- テラバイト規模の通信ログ、AWSの操作履歴、脅威の検出結果を継続的に自動収集し、グラフモデルにまとめる
- ユーザのデータ収集・管理時間を節約
- 使いやすい視覚化
- 機械学習、統計分析、グラフ理論を利用したインタラクティブな視覚化
- ユーザがデータを整理したり、独自のクエリやコード、アルゴリズムを開発、構成、調整する必要はない
Amazon Detective のユースケース
- アラートのトリアージ
- 脅威検出結果の分析
- アラートが True Positive(正しい検出)か False Positive(誤った検出)か素早く分析
- 分析例
- 送信データのサイズは？
- この通信は常時発生しているのか？
- インシデントの前に何が起きたか？
- API コールの失敗は異常なことか？
- False Positive なら不要な調査を回避
- True Positive と判断、または FalsePositive の判断ができない場合
- 優先順位をつけて、インシデント調査へ
- 脅威検出結果の分析
- インシデント調査
- 影響範囲の特定
- インシデントの根本原因や、被害の影響を特定するための本格調査
- 他のデータと相関させた深い調査
- 関連するリソースにも拡大して実施
- 分析例
- この IP アドレスがコールした API は？
- この API コールは偵察活動か？
- 他に悪用された Principal ID はあるか？
- この IP と通信している EC2 インスタンスはあるか？
- 影響範囲の特定
- スレットハンティング
- 侵害痕跡の調査
- 内外の Indicator of Compromise(侵害の痕跡)を元に自組織にも影響があるか調査
- 分析例
- 脅威レポートで報告されたIPアドレスが過去1年間にEC2インスタンスと通信をしたか？
- 疑わしい User Agent の全ての API コールを確認
- 侵害痕跡の調査
Amazon Detective の利用方法
- 前提サービス Amazon GuardDuty 有効化の48時間経過後
- Amazon Detective のコンソールに移動し有効化
- 有効化後は24時間程度、データの収集とグラフモデルへの変換を待つ
- Detective は AWS 内部で CloudTrail の証跡を収集している
- Detective のサーチコンソールにて自身のグローバルアドレスを検索
セキュリティ分析の調査プロセス
- 調査の起点として、Detective と統合された Amazon GuardDuty または AWS Security Hub から脅威を確認
- トリアージ
- このインシデントは False Positive(誤検知)か True Positive(真の検知)か？
- いつから発生か？まだ続いてるのか？
- インシデント調査
- どのユーザーがいつEC2インスタンスを起動したのか？
- EC2 インスタンス は他の不正を行っていないか？
スレットハンティングのフロー
- Indicator of Compromise (侵害の痕跡)を元に、Detective のプロファイルを呼び出して分析
- トリガーの例
- 内外のセキュリティ侵害レポート
- IP address
- User agent
- CPU 使用率が突然上昇した EC2 インスタンス
- 月次の定期分析
- 内外のセキュリティ侵害レポート
Detective 内部の分析プロセス詳細
- AWS リソースからテレメトリの自動収集
- テレメトリは、ソフトウェアやアプリケーションがパフォーマンス改善や品質向上を目的として収集するユーザーの利用状況データのこと
- 収集のために特別な設定は必要ない
- 開始後2週間は機械学習のトレーニング期間
- 継続的な集約とグラフモデルへの変換
- データ分析処理
- コンテキストを視覚化
マルチアカウント対応
- 他の AWS アカウントを Detective のメンバーとして招待
- 招待元のアカウントがマスターアカウントとなる
- アカウントを横断してセキュリティ調査が可能
マルチアカウントのテレメトリの収集
- マスターアカウントのグラフモデルに、メンバーアカウントのテレメトリが提供される
- マルチアカウントから収集すると分析精度が高まる
スクリプトによるマルチアカウント一括有効化
- マルチアカウント有効化のスクリプトが Github で公開されている
マルチアカウント時の GuardDuty / Security Hub との統合
- マルチアカウントでも GuardDuty / Security Hub と統合可能
- GuardDuty / Security Hub のマスターアカウントと Detective のマスターアカウントを同一にすることを推奨
- マスターアカウントはメンバーアカウントが検知した脅威を迅速に調査可能
- 同一にできない場合、クロスアカウントロールを設定し、Detective のマスターアカウントが GuardDuty / Security Hub のマスターアカウントにアクセス
プロファイルへの URL リンク
Amazon Detective のエンティティまたは検出結果のプロファイルについて、
直接参照するための URL リンクを生成可能。
- URLリンクによる他システムとの連携
- SIEM / アラートコンソールセキュリティ
- オーケストレーション / チケットシステム
おわりに
インシデント対応で Amazon Detective を用いることで、
迅速な調査が可能になり、被害を最小化できる、すごい。
次回は、Amazon GuardDutyです。お楽しみに。