
【レポート】AWS 環境における脅威検知と対応 #AWSSummit
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、岩城です。
2019年6月12日(水)〜2019年6月14日(金)の 3 日間にわたり、 千葉県の幕張メッセにて AWS Summit Tokyo 2019 が開催されています。
こちらで講演されたセッション「 AWS 環境における脅威検知と対応」を聴講しましたのでレポートします。
概要
このセッションでは、日々数百数千、ときに何万も発生するセキュリティアラートを、一元的に集約、整理、優先順位付け、自動化された対応プロセスを実現する方法についてご紹介します。AWS のベストプラクティスと所属組織が従う業界標準に基づく自動化されたコンプライアンスチェックを使用して、継続的に環境をモニタリングする、AWS環境における脅威の検知およびその対応方法に関する最新の技術を学びます。関連サービスは、AWS Security Hub, Amazon GuardDuty, Amazon Inspector, Amazon Macie, AWS CloudTrail, Amazon CloudWatch, AWS Lambda などです。
スピーカー
- アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
 - 藤倉 和明
 
※敬称略
レポート
自己紹介
- 主に流通のお客様を担当
 - セキュリティのバーチャルチームに所属
 - 好きなサービス
 - CloudWatch
 - VPC
 - AWS WAF
 - 好きな食べ物
 - 新潟県出身のため白米
 
本セッションの対象者とゴール
- 対象者
 - AWS管理者
 - IT全般管理者
 - セキュリティ管理者
 - セキュリティ担当
 - AWSデベロッパー
 - ゴール
 - AWS環境における脅威検知とその対応方法のベストプラクティスを学び、今日から実践できる手段について理解する
 
本セッションのポイント
- 脅威検知のために4つのサービスを有効化する
 - 脅威への対応プロセスを理解する
 
4つのサービスを有効化する
- これらを有効化することで脅威検知プロセスを開始することができる
 - Amazon GuardDuty
 - AWS Config
 - AWS CloudTrail
 - Security Hub
 
なぜ脅威検知は難しい?
- 大量のデータ・セット
 - デバイス
 - 攻撃手法
 - 高い検知精度の要求
 - フォールスポジティブだと誤検知が発生する、フォルスネガティブだと攻撃を受ける
 - 人材とスキル不足
 
イベントとインシデントの違い
- 脅威はインシデントを引き起こす潜在的な原因
 - すべてのインシデントはイベントに含まれる
 - すべてのイベントはインシデントではない
 - 膨大なイベントからごく一部のイベントがインシデント
 
まずはイベント収集する
- AWS CloudTrail
 - AWS上のアカウントのアクティビティログを継続的に記録することができる
 - 新規アカウントはデフォルトで有効化され、7日間保持される
 - 7日間以上保持したい場合はS3にログを保存する
 - AWS Config
 - AWSリソースの設定を評価、監査、審査する
 
AWS CloudTrail
- AWSユーザの操作をロギング
 - ユーザのアクティビティをAPIレベルでトラッキング
 - ロギングデータはS3に保存する
 - ログは暗号化される
 - 無料かつデフォルトで有効化される
 - いつ、誰が、何をしたのか記録されている
 - いつ、誰が、コンソールにログインしたか
 - いつ、誰が、SecurityGroupを変更させたか
 
AWS Config
- AWSリソースのレポジトリ情報からリソースの変更履歴、構成変更を管理
 - 定期的に構成情報のスナップショットをS3に保存
 - 変更を検知してSNSで通知することも可能
 - Config Rules
 - 構成情報をもとに「現在あるべき姿」になっているか、コンプライアンスが守られているかを評価
 
コンフィグタイムラインの自動収集
- 設定変更やリレーションシップの変更履歴がタイムラインで自動収集される
 - あるWEBサーバがいつから脅威にされされているかを確認するのに有用
 
イベントから脅威を検知するのは難しい
- ログ情報の統合、分析、システムのセキュリティ状態の総合的な管理
 - 大企業でも29% 中小企業7%が実施
 - ログを活用した対策が普及しているとは言い難い
 - 効果、費用対効果が分からない
 - 経営層が境界防御以外のセキュリティに対して投資したがらない
 - 運用人材の不足
 
膨大なログから脅威を検知する
- Amazon GuardDuty
 - 悪意のある行動を継続的に監視する
 - 攻撃者からの偵察、EC2のリスク検知
 - Security Hub
 - AWS環境におけるセキュリティとコンプライアンス状態をダッシュボードで一元表示
 - Security担当がダッシュボードを見て脅威対応プロセスを開始する
 
Amazon GuardDuty
- VPC フローログ
 - DNS ログ
 - CloudWatch Event logs
 - 機械学習学習による脅威検知インテリジェンス
 
悪意あるスキャン
- インスタンスへの脅威
 - アカウントの脅威
 - インスタンスへの脅威とアカウントの脅威を組み合わせてブルートフォースアタックされていることを検知できる
 - High、Medium、Lowで評価
 
Security Hub
- セキュリティとコンプライアンスの状態を一元的に表示できる
 - 脆弱性診断 Amazon Inspector
 - Amazon Macie
 - AWS Config
 - 重要度の高いセキュリティイベントを利用できる
 - Public Previewなので注意
 - 追加料金無しで利用可能
 - 異常な行動をしているEC2やAWSアカウントがいくつあるかなどを表示される
 - 脅威イベント(insights)をカスタムinsightsで定義することができる
 - 例えば、2ユーザが怪しい動きをしている
 - ドリルダウンするとAmazon GuardDutyやAmazon Macieの情報を確認しながら、本当に不正なアカウントか確認する
 
脅威への対応:カスタムアクション
- セキュリティ担当者はEC2インスタンスにログインすることができないが、Secutiry Hubでの検知を受けてEC2を止めたい、バックアップ取得したい場合
 - Cloud Watch Eventに連携され、Lambdaが実行され、EC2インスタンスに対しストップインスタンスを実行できる
 - EC2への直積なアクセスができなくとも、脅威が認められたインスタンスに対してアクションできる
 - Githubにカスタムアクションのサンプルを公開
 
追加で検討するサービス
- イベント収集
 - VPC Flow logs
 - VPCを出入りするトラフィックログを取得する
 - CloudWatch Logs
 - アプリケーションログの監視保存
 - 脅威検知
 - Amazon Inspector
 - EC2インスタンスへの自動セキュリティ評価
 - Amazon Macie
 - 機械学習による機密情報の検出、分類、保護
 
マルチアカウントの対応も検討
- 例えばアカウント1〜3のアクティビログをセキュリティ管理用アカウントに集めて統一したレベルで脅威に対する体制を構築する
 
脅威への対応プロセスを理解する
- NISTのサイバーセキュティフレームワーク
 - ホワイトペーパーも公開されている
 - 本セッションはdetectからrecoverを話す
 
脅威への対応プロセスを2つに分けて整理する
- 検知"した"脅威への対応
 - 検知"する"脅威への対応
 
検知した脅威への対応
- Security Hubが脅威を検知して対応を開始する
 - 脅威(insights)が見つかった
 - 収集したイベントの中から確認する
 - インスタンスを停止したり、フォレンジックのための行動を取る
 - イベントを収集、集約し、エンジニアが確認し、対応する
 
検知する脅威への対応
- Security Automationの重要性
 - 拡張性、コスト、信頼性の観点からクラウド時代ではセキュリティの自動化は不可欠
 - セキュリティの自動追従、労力時間の削減、品質の担保、人為的ミス排除
 - 対応速度を上げる
 
イベントドリブンな脅威への対応
- AWS Config Rules
 - 
継続的にリソース変更を監視し、定義ルールへの準拠状況を通知
 - 
AWS Cloud Watch Events
 - AWSリソース変更をリアルタイム検知
 
Config Rules
- AWS リソースの変更履歴や設定変更を管理
 - あるべき状態になっているかどうかを継続的に評価
 - 公開状態になっているS3バケットがあるか
 - すべてのIAMユーザでMFA有効化されているか
 - 80個を超えるAWSマネージドルールを利用できる
 - S3バケットがパブリック読み路取りアクセス許可されていないこと
 - SSH受信ポートが制限されていること
 - などなど
 
Cloud Watch Events
- ルールを定義して、イベントソースとターゲットを紐付けるサービス
 - イベントソースとして各種サービスを選択可能
 - ターゲットはSNS、Lambdaなど
 
定期的に自動的に処理を行う
- スケジュール
 - 定期的な処理を実行する
 - イベントパターン
 - 様々なイベントをトリガーにターゲットの処理を実行する
 
利用例
- Amazon GuardDutyのfindingsからCloud Watch EventsをトリガーにLambdaを起動
 - Slackへの通知、JIRAのチケット起票、pagerdutyへの通内
 
脅威対応サービス
- Lambda
 - 脅威はいつ発生するか分からない
 - 分からないもの対してリソースを確保するのは非効率的
 - サーバレスの実行環境は相性が良い
 - SSM
 - インスタンスにエージェントをインストール
 - シェルを用意しておきリモートで実行して情報を取得できる
 - StepFunctions
 - 複雑なセキュリティのワークフローを定義
 - スナップショット、停止、通知
 
セキュリティワークショップ
- AWS上で擬似的な攻撃をし、脅威検知、調査、通知、修復、追加保護策を体験できる
 - プロダクションではやらないこと!
 
まとめ
- 脅威検知のために4つのサービスを有効化する
 - Amazon GuardDuty、AWS Config、AWS CloudTrail、Security Hub
 - +αで有効化する
 - 
VPC Flow Logs、CloudWatch Logs、Amazon Inspector、Amazon Macie
 - 
脅威への対応プロセスを理解する
 - 検知した脅威への対応
 - Security Hubを起点に脅威検知とその対応プロセスを開始
 - 検知する脅威への対応
 - セキュリティの自動化は不可欠
 - Cloud Watch Events、AWS Config rulesでイベントドリブンに対応する
 







