AWS 環境におけるセキュリティインシデントの調査・対応⽅法 · © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS 環境におけるセキュリティ

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

AWS 環境におけるセキュリティインシデントの調査・対応⽅法中島章博アマゾンウェブサービスジャパン技術統括本部ソリューションアーキテクト

Twitterハッシュタグ #AWSInnovate


本セッションについてセッションの対象者

• AWS環境のシステムでセキュリティ監視とインシデント対応を検討または始めたばかりの⽅• 企業のCSIRT等でセキュリティ統制を⾏っている⽅• AWS環境に対してどのようなセキュリティのインシデント対応ができるかを知りたい⽅

セッションのゴール• AWS環境でインシデント対応の⽅法を知り、セキュリティ監視の準備と基本的な調査ができるようになる

今回扱う課題リスト• セキュリティインシデントに気づく⽅法がわからない• インシデント情報が多く何から⼿をつけたら良いかわからない• 分析・調査は何をすれば良いかわからない• 毎回、同じインシデント対応の繰り返しが負担

【ご連絡事項】本セッション内容について確認するためのクイズおよび簡単なアンケートがセッションの最後にあります。なおクイズの回答はアンケートとあわせて表⽰されます。


アジェンダイントロダクション︓セキュリティインシデント対応の重要性

お客様からよくご相談いただくインシデント対応の課題

AWS環境におけるインシデント対応の課題解決⽅法

まとめ

クイズ



コンピューターセキュリティインシデントとは︖組織が定めるセキュリティポリシーやコンピューターの利⽤規定に対する違反⾏為または差し迫った脅威、あるいは、標準的なセキュリティ活動に対する違反⾏為または差し迫った脅威を⽰す

サービス不能悪意のコード不正アクセス不適切な使⽤

※引⽤︓NIST SP 800-61 rev.1「コンピュータインシデント対応ガイド」(IPA⽇本語翻訳版)

https://www.ipa.go.jp/files/000025341.pdf


セキュリティインシデント対応が重要な理由攻撃により個⼈データや業務データが頻繁に損なわれている

インシデントレスポンスを適切に実施するとl 迅速かつ効率的にセキュリティインシデントから復旧するのを助けるl 情報の損失や盗難、サービスの中断を最⼩限に抑えることができるl 事件処理の際に得た情報を使って、将来の事件に備え、システムとデー

タを強⼒に防護できるl 事件に伴って発⽣する可能性がある法的な問題を正しく扱える

※引⽤︓NIST SP 800-61 rev.1「コンピュータインシデント対応ガイド」(IPA⽇本語翻訳版)

https://www.ipa.go.jp/files/000025341.pdf


本セッションのスコープ(1)

Protect Detect Respond

Automate

Investigate

RecoverIdentify

AWS Systems Manager

AWS Config

AWS Lambda

Amazon CloudWatch

Amazon Inspector

Amazon Macie

Amazon GuardDuty

AWS Security Hub

AWS IoT Device

Defender

KMSIAM

AWS Single

Sign-On

Snapshot ArchiveAWS CloudTrail

Amazon CloudWatch

Amazon VPC

AWS WAF

AWS Shield

AWS Secrets

Manager

AWS Firewall Manager

AWS Organizations

Personal

Health Dashboard

Amazon Route 53

AWS Direct

Connect

AWS Transit Gateway

Amazon VPC

PrivateLink

AWS Step Functions

Amazon Cloud

Directory

AWS CloudHSM

AWS Certificate Manager

AWS Control Tower

AWS Service Catalog

AWS Well-Architected

Tool

AWS Trusted Advisor

Resource Access

manager

AWS Directory Service

AmazonCognito

Amazon S3 Glacier

AWS Security Hub

AWS Systems Manager


本セッションのスコープ(2)お客様のAWS環境におけるセキュリティインシデント(責任共有モデルのSecurity in The Cloud)

クラウドセキュリティの3つのインシデントドメイン

本セッションはサービスドメインとインフラストラクチャの⼀部を対象

ドメインの説明対応⽅法

サービス AWSアカウント、IAM権限、リソースメタデータへの侵害、不正利⽤の請求など

AWS固有の設定に起因するためAWS APIのログを分析

インフラストラクチャ

EC2インスタンスへの通信、EC2インスタンス内のプロセスやデータの侵害など

⼀般的なフォレンジックツールを使⽤。場合によってはAWS APIのログを分析

アプリケーション

アプリケーションコードやソフトウェアのデプロイに起因

お客様固有のアプリケーションやデータベースログの分析

AWS セキュリティインシデントレスポンスガイド(英語)

https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf



セキュリティインシデント対応の課題① セキュリティインシデントに気づく⽅法がわからない

② インシデント情報が多く何から⼿をつけたら良いかわからない

③ 分析・調査は何をすれば良いかわからない

④ 毎回、同じインシデント対応の繰り返しが負担








セキュリティインシデントに気づく⽅法• 捜査機関、JPCERT/CC等の第三者からの通知を受取る

• AWSからのAbuse通知を受取る

• システム不具合や異常状態の調査時に発覚する

• お客様がセキュリティ監視をしてプロアクティブに検出する

ご参考︓⾃分のリソースについて AWS から不正使⽤の報告を受けました - どうすればよいですか?

課題① セキュリティインシデントに気づく⽅法がわからない

https://aws.amazon.com/jp/premiumsupport/knowledge-center/aws-abuse-report/


インシデントの痕跡が残っている主なログ

DNS Logs

ユーザーアクティビティと API 使用状況の追跡ログ

VPC のネットワークインターフェイスで送受信されるトラフィック

ログ

(各システムから収集した)アクセスログ等

VPC内のAWS DNSリゾルバーへのクエリー

ログ

AWS CloudTrail VPC Flow Logs Amazon CloudWatchLogs



マネージド型脅威検出サービスの活⽤

VPC Flow Logs

DNS logs

CloudTrail

検出結果データソース

既知の脅威脅威

インテリジェンス

未知の脅威異常検出

(機械学習)

AWS Security Hub

• 対策⾃動化• パートナー

ソリューション• SIEM連携

CloudWatch Event

検出結果タイプ(例)

ビットコインマイニングC&C活動

異常なユーザーの挙動ユーザーの追加削除変更ネットワーク権限の変更

Amazon GuardDuty脅威検出タイプ

HIGH

MEDIUM

LOW

異常なトラフィックパターン特定ポートへの異常な通信量

S3 bucket

※ご参考︓GuardDuty 結果形式 - アクティブな結果タイプ


https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html


GuardDutyの検出結果例

偵察インスタンスの侵害

アカウントの侵害

通常と異なる API アクティビティ

悪意のある既知の IP

通常と異なるポート

ポートスキャン

通常と異なるトラフィック量

通常と異なるインスタンスまたはインフラストラクチャの起動

匿名化プロキシ通常と異なるリージョンでの起動

ビットコインアクティビティ

DNSを⽤いた不正通信

CloudTrail の無効化

RDP/SSH ブルートフォース



インシデントに気づくための準備• セキュリティ監視とインシデント調査に必要なデータを事前に収集する

ことが必要です

• AWS環境のサービスドメイン/インフラストラクチャードメインの場合脅威検知︓GuardDuty調査︓GuardDuty、CloudTrail、VPC Flow Logsなど

• ログの検索/分析⽤にログ転送(推奨)

VPC Flow logsAWS CloudTrailAmazon GuardDuty

Amazon CloudWatch

SIEM(パートナーソリューション)

その他のログ

転送


Amazon Elasticsearch Service







インシデント情報に優先度をつける最初から全てのインシデントに対応をするのではなく優先度をつけて対応

例) GuardDutyの危険度の⾼い検出結果や重要なサーバーでフィルター

初期調査で推奨のGuardDuty検索タイプl UnauthorizedAccess:IAMUser/InstanceCredentialExfiltrationl UnauthorizedAccess:IAMUser/TorIPCallerl CryptoCurrency:EC2/BitcoinTool.B!DNSl CryptoCurrency:EC2/BitcoinTool.Bl Recon:EC2/PortProbeEMRUnprotectedPortl UnauthorizedAccess:EC2/TorClientl UnauthorizedAccess:EC2/TorRelay

課題② インシデント情報が多く何から⼿をつけたら良いかわからない


【例】複数条件のフィルターの⽅法(1)

画⾯右上に検出結果の総数と重要度別にカウント数が表⽰される。⼀度のインシデント調査で対応できる程度にフィルターする


GuardDutyコンソール



検索タイプ(Finding type)を選択





フィルターしたい検索タイプを⼊⼒して「適⽤」をクリック





フィルターした検索タイプのみ表⽰





同様の⽅法で複数の検索タイプを条件に追加。画⾯右上の表⽰中が7件に限定されている。検索ボックス右の「保存」で条件を保存して、次回からフィルター条件を呼び出せるようにする。





フィルター条件の名前と説明を⼊れて、画⾯右下の「保存」をクリック





保存したフィルターは画⾯右上のプルダウンに保存され、いつでも呼び出し可能









分析・調査の⽬的・セキュリティインシデントであるかの結論を迅速に導き出す

⇒ 被害を最⼩化するため

・インシデントによる影響と被害があればその内容を確認する⇒ 事後対策のため

・インシデントの根本原因を特定する⇒ 再発防⽌策のため

課題③ 分析・調査は何をすれば良いかわからない


調査の観点とプロセスⅠ 検出結果タイプそのものの内容を理解するⅡ 誤検出または受容できるリスクかを判断するⅢ 本格調査をするⅣ 完了した調査をクローズする

課題③の解決⽅法は次の検出結果の分析を例に説明「UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration」



Ⅰ 検索タイプそのものの理解迅速かつ正確に調査し、セキュリティインシデントの詳細把握をするには、検出した検索タイプそのもの理解が不可⽋です

理解後にできることの⼀例l なぜ検出したかのロジックの把握l 正常通信を誤って検出(誤検出)したかの判断l お客様環境でのリスク評価l 関連ログの特定



Ⅰ【例】検出結果と詳細確認

① 確認したい検出結果を選択

② 画⾯右に詳細情報が表⽰される

③ 検索タイプの説明ページへのリンク




Ⅰ【例】検索タイプ説明ページの確認

検出ロジック

誤検出のパターン被害時の対応⽅法誤検出有無の確認⽅法



Ⅰ【例】説明ページから得られたこと・EC2内で⽣成された認証情報を窃取され悪⽤された可能性あり・デフォルトの危険度︓⾼・検出ロジック︓EC2⽣成の認証情報をEC2以外からAPI呼び出しで発⽣・誤検出︓オンプレ経由でグローバルIPを使ってAPI呼び出しをしてる等・確認⽅法︓IAMユーザーの特定⽅法・被害時対応⽅法︓AWSアカウントが侵害された場合の説明ページへ

検出結果の理解により次のステップの調査⽅針が明確になる



Ⅱ 誤検出または受容できるリスクかを判断想定できる、または受容可能なリスクのイベントかを判断する

判断基準例）• 脆弱性診断ツールによるポートスキャン• 要塞化されたホストへのSSHの総当たり攻撃• インターネットに公開しているサービスへのポート調査(Web

サーバーなど)

問題ない検出結果と判断できない ⇒ 次のプロセスへ問題ない検出結果と判断できる ⇒ 次はスキップ



Ⅱ【例】正常通信の誤検出かを確認するActor︓今回の場合は通信元• IP Addressはお客様のIPですか︖

• Locationはお客様拠点の所在地ですか︖

• Organizationはお客様がご契約されてるISPですか︖


GuardDuty 結果の検索と分析

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_findings.html


Ⅲ 本格調査問題ない検出結果と判断できなければより深い調査

準備︓構成図等からインシデントが発⽣したシステムを把握痕跡の残るログをできる限り収集し結びつける

ログ分析・調査の仮説検証アプローチの例・調査⽬的を決め、仮説を⽴てる・ログから正常と異常値/外れ値にデータを分類(⽬視、統計、視覚化)・特定のキー(特に異常値/外れ値)で関連ログを抽出・抽出した関連ログを分析し、仮説の検証を繰り返す

最終の調査⽬的︓セキュリティインシデントか︖影響と被害範囲は︖根本原因は︖の結論を得ること



Ⅲ【例】攻撃の最初の時間を特定する(1)【⽬的】攻撃の最初の時間を特定したい【仮説】IP(198.51.100.0)で抽出すれば判明するはず【調査】GuardDuty、CloudTrail、VPC Flow LogsをこのIPで検索

■GuardDutyで検索検索式︓「API 発信者の IPv4 アドレス」に198.51.100.0でフィルター

■CloudTrailをCloudWatch Logs Insightで検索検索式︓filter sourceIPAddress="198.51.100.0"



Ⅲ【例】攻撃の最初の時間を特定する(2)■VPC Flow LogsをCloudWatch Logs Insightで検索検索式︓filter srcAddr="198.51.100.0"

■VPC Flow LogsとCloudTrailをCloudWatch Logs Insightで串刺し検索検索式︓filter srcAddr="198.51.100.0” or sourceIPAddress="198.51.100.0”

【検証】他のIPからはあり得ないのか︖漏洩した認証情報(アクセスキー)でログ検索した場合は︖



Ⅳ 完了した調査をクローズする• 調査が完了したセキュリティインシデントはクローズにして、対処済み

と未対応のインシデントを区別できるようにします。• それによって新規に発⽣したインシデントを迅速に対応できます。

• GuardDutyではアーカイブ機能を使うことで実現できます



Ⅳ【例】調査完了の検出結果をアーカイブ(1)

① アーカイブしたい検出結果にチェックを⼊れる

② プルダウンメニューのアーカイブをクリック




Ⅳ【例】調査完了の検出結果をアーカイブ(2)

③ 検出結果の⾮表⽰を制御最近︓アーカイブなしのみ表⽰アーカイブ済み︓アーカイブしたものを表⽰すべて︓すべてを表⽰









インシデント対応の効率化• 原因分析の結果を防御の設定に反映

• 対応⼿順が固まったものはセキュリティ⾃動化を実装

• 繰り返し発⽣する問題ない検出結果の抑制

課題④ 毎回、同じインシデント対応の繰り返しが負担


【例】GuardDuty検出結果の抑制⽅法(1)

① 抑制したい条件でフィルターを指定

② 抑制したい検索タイプだけが表⽰されていることを確認

③ 抑制ルールとして保存



【例】GuardDuty検出結果の抑制⽅法(2)

① 抑制したい条件でフィルターを指定

② 抑制したい検索タイプだけが表⽰されていることを確認

③ 抑制ルールとして保存

④ 抑制ルールの名前と説明

⑤ 保存をクリック



まとめ


まとめ① セキュリティインシデントに気づく⽅法がわからない

⇒ セキュリティ監視。GuardDutyで脅威検出後、ログの分析②インシデント情報が多く何から⼿をつけたら良いかわからない

⇒ 優先順位をつけて対応。GuardDutyはフィルター機能③ 分析・調査は何をすれば良いかわからない

⇒ 仮説/抽出/分析/検証の繰返し。原因分析と影響評価を⽬的④ 毎回、同じインシデント対応の繰り返しが負担

⇒ 根本原因対策、セキュリティ⾃動化、抑制機能を活⽤



クイズ

AWS環境上でEC2による3層構造のWebシステムが稼働しており、GuardDutyで脅威検知とセキュリティ監視をしています。

ある⽇、GuardDutyで”UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration”を検出しました。⾃社のIPアドレスからではなかったので攻撃と判断。悪⽤された認証情報はEC2のIAMロールの⼀時的な認証情報でした。即座にこの認証情報を無効化したので被害は発⽣しませんでした。

調査した結果、外部からOSコマンドインジェクションでこの認証情報を窃取されていたことがWebアプリケーションログから判明しました。しかし、GuardDutyではこの攻撃を検出していなかったです。

なぜ検出できなかったのでしょうか︖この攻撃を検出する⽅法はありますか︖

Thank you!


Akihiro Nakajima

Documents

AWS 環境におけるセキュリティ インシデントの調査・対応⽅法 · © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS 環境におけるセキュリティ

AWS 環境におけるセキュリティインシデントの調査・対応⽅法 · © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS 環境におけるセキュリティ