この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、AWSのインシデント調査してますか？(挨拶
今回はみなさんに嬉しいお知らせができるのでチョー喜びながら書いてます。まずは以下を見てください。AWS上のセキュリティイベントが関連付けられて並べられています！
よくないですか！？
AWSで起きた問題を調査する時にめっちゃ欲しい図です！
というわけで今回はRadware社のCloud Native Protector(CNP)という製品でAWSのインシデントレスポンスをしていくところを紹介していきます。上記のいい感じの図は後で詳しく説明します。
概要
Radware社はクラウドもオンプレミスも守ってくれるセキュリティ企業です。DDoS対策とかKubenetesセキュリティとかWAFとかいろいろあります。
Cloud Native Protectorはクラウドセキュリティの製品です。上述したインシデントレスポンスのための機能や危ない設定を検知するいわゆるCSPMの機能を持ってます。
私がこのCNPの良いと思うところはインシデントの調査がとても捗るところです。
AWSネイティブのこのあたりの機能はGuardDutyとDetectiveがあります。どちらも非常に役に立ちます。GuardDutyはAWS上の様々な脅威を検知し、Detectiveはその調査ができます。Devectiveの調査は各リソースの関連付けやGeoロケーションの可視化などログの解析を直接行わなくても様々なインサイトを得ることができます。
しかし私は唯一Detectiveに足りないと思っていることがあります。それが上述したイベントを関連付けて可視化する機能です。
というわけでCNPを使うとよりインシデントの調査がはかどります。というか誰が何をどうした、という攻撃の流れが一連のフローにまとめられているので完全に理解できます。やったぜ。
CNPにはなんとAttack Simulationという攻撃を実際にテストして可視化を試す機能が利用可能です。というわけで今回はAttack Simulationを利用してRDS/EBS/S3などの情報漏えいをシミュレーションして使い勝手を確認していきます。
やってみた
CNP利用からAttack Simulationまでの流れは以下のとおりです。
- AWSアカウント連携
- ログ収集設定
- Attack Simulation用IAM設定
- Attack Simulation
途中のセットアップが結構長めなので、調査部分だけ見たい方はAttack Simulationまで飛ばしてください。広い画面で見ている方は左側リンクからどうぞ。
AWSアカウント連携
CNPの画面はこちらからアクセスします。SaaS型ですが、サインアップリンクは現在お問い合わせページへのリンクとなっています。お問い合わせしてね☆ミ
はじめてログインしたらクラウドアカウントの連携から開始します。AWSのアカウントを登録していきます。
連携方法はIAM Roleを作成して権限渡す形です。というわけでRoleの作成。丁寧なスクショ付き手順が出てくるので、途中で利用するCNP側のAWSアカウントIDと外部IDをコピーしてIAM Role作成画面を開きます。
IAM Role画面から作成していきます。
別のAWSアカウントを選択して先ほど控えたAWSアカウントIDと外部IDを入力します。
CNPの画面に戻って次はポリシーです。AWS管理ポリシーのSecurityAuditとAWSWAFReadOnlyAccessをアタッチします。Role名前はRadwareCNP_Accessが推奨されています。
AWSマネジメントコンソールに戻って2つのポリシーをそれぞれ検索してチェックを入れます。
タグは特に必要無いので次へ進み、名前を入れて作成します。
作成できたらIAM RoleのARNを控えます。
CNPに戻ってARNを入力します。登録するAWSアカウントの重要度も選択できますので適当に。
登録したらしばらくベルトコンベアのGifが流れてAWSアカウントのリソース調査とかされます。かわゆ。
完了したら各種リソースの設定を調査した結果が出ます。これを細かくチェックしていってもいいですが、今回の趣旨はCSPMではなくAttack Simulationなので次のログ収集の設定を進めます。
ログ収集設定
収集する対象はCloudTrailとVPCフローログです。まずはTrailから。私のアカウントではすでにCloudTrailの設定があるので、その設定と保存先のS3バケットが出てきます。早速連携したIAM Roleが生きていますね。そのまま次へ。
VPCフローログも同じような感じです。監視対象のVPCでVPCフローログが設定されているか・S3に保存されているか確認しましょう。リフレッシュボタンがあるのでAWS側に行って設定してからここに戻ってきても大丈夫です。
保存対象を確認できたらCNPが専用のポリシードキュメントを作成してくれます。該当するS3に対するアクセス権限が記述されています。推奨されるRadwareCNPLogAccessという名前でIAM Policyを作成していきます。
AWSマネジメントコンソールでIAMのポリシー作成へ。JSONタブでコピーしたドキュメントを貼り付けて次へ。
名前を入れて作成します。
続いてさっき作成したIAM RoleにPolicyを追加します。詳細画面でアクセス権限タブからポリシーをアタッチします。
名前入れてチェック入れてアタッチします。
アタッチできたらCNPの画面に戻りログの通知設定をします。各ログがS3に保存されたらRadware側のSNSに通知するようにします。コピーボタンで通知先SNSのARNを控えて「GO TO AWS」でログ保存先S3バケットを開きます。
S3バケットのプロパティタブから設定します。
下の方に行くとイベント通知設定があるので作成します。
名前は適当に、今回はRadwareCNPCreateNotificationとし、プレフィックスはログ保存先なので今回はAWSLogs/としました。通知イベントタイプは「すべてのオブジェクト作成イベント」にチェックを入れます。
送信先にSNSトピックを選択してARNを入力して保存します。
S3バケットの分繰り返したらそれぞれ「VERIFY」ボタンを押して問題ないか確認します。すべて問題なければ進みます。
これで初期設定は完了です。「Hardening」タブで設定の状態について色々出てくるのでチェックしていくといいでしょう。
Attack Simulation用IAM設定
Attack Simulation機能です。実はこの機能はリクエストしないと解禁されないので、使いたい場合はRadwareさんにリクエストしてください。(多分リクエストしたら使えるハズ？)
まずAttack Simulationタブを開くと右側にセットアップボタンがあるのでこちらから始めます。
Attack Simulationは攻撃と同じ動作をするので追加の権限が必要です。IAM Roleとそれに使うPolicyを作成します。まずはポリシードキュメントが表示されるのでこれを作成します。RadwareCNP_attack_simulationという名前で作成します。AWS側の手順はほぼ同じなので割愛します。
作成したPolicyをアタッチするIAM Roleも作ります。名前の指定は特にないのでRadwareCNP_attack_simulation_Roleという名前で作成しました。これもAWS側の詳細手順は割愛します。
作成したIAM RoleのARNを入力して完了です。
Attack Simulation
おまたせしました。いよいよ本題のAttack Simulationです。この機能は実際の攻撃をシミュレーションしてCNPでどのように調査できるかを体感できます。攻撃の種類は現状以下の3つが見えています。
- クラウドネイティブデータ漏洩
- コインマイニング
- RDSデータ漏洩(Coming Soon)
今回はクラウドネイティブデータ漏洩を使って、1つのIAM UserがAWSアカウントへ侵入・調査のフェーズを得て権限昇格した後、EC2を作成しRDS/EBS/S3/Redshiftの情報を搾取する一連の攻撃を実際のAWS環境上に発生させ、これを調査します。もちろん対象AWS環境にある実データが漏洩するわけではなく、シミュレーション用の各種リソースが作成されそのデータが擬似的に漏洩するだけです。漏洩先は不特定多数ではないためその点は大丈夫です。
Attack Simulationタブから「Cloud native data exfiltration」の詳細画面に移動します。ざっと全体像を確認します。一旦わかりやすくお見せするためにGoogle翻訳した画面で説明します。画面左上にはAttack内容の説明があり、下の方には攻撃フローがわかりやすく図になっています。図がきれいなので眺めていきます。セットアップから始まって調査後IAM Roleが作成されます。
EC2が作成されRDS/EBSが漏洩します。
S3バケット・Redshiftのスナップショット・AMIが共有されて完了です。いっぱい漏れちゃいますね。
それでは実行していきます。画面右上でこのシミュレーションを行う対象サブネットを選択できるので選んで実行します。
ステータスが変わり下のフローの波線がプログレスバーとしてグラフィカルに進んで行きます。
各フェーズごと色分けされていていい感じです。
こんな感じにぐねぐねと進み…
環境がクリーンアップされて完了です。
所要時間としては10分程度でした。しばらくするとこのシミュレーションに対するアラートが作成されます。アラートはCNPでは各種セキュリティイベントを集約して1つにまとめて管理されます。これを確認しましょう。
アラートの詳細画面です。ここがすごく良いところです。上部には攻撃に関連するIAM情報や行われた攻撃の概要がありますが、そんなことより下にあるAttack Storyという攻撃の一連のフローと関連性を表す図です。攻撃者がどのクレデンシャルで何を行い、どの攻撃に派生したのかひと目で分かります。
横に長いので右に矢印ボタンでスクロールする感じになっています。途中でフローが派生していて、攻撃者がどのような行動を取ったか非常にわかりやすいです。今回は2つのフローがあり、途中のInstance Creationイベントで派生していることがざっくりつかめます。
それぞれのイベントの詳細を見ていきます。最初の方では様々なAPIの失敗から始まります。各種リソースの一覧を確認する行動から、このIAM Userが攻撃者でありAWS環境の調査を始めている可能性を示唆しています。
次に攻撃者はIAM Roleの作成に成功します。権限昇格の行動として検出されています。この次のイベントではAdministratorAccess権限が付与されいよいよ危ない状況であることも確認できます。
そして分岐点のところです。作成したIAM RoleをアタッチしたEC2インスタンスが作成されます。ここから派生するのは、最初のIAM UserではなくAdministartor AccessがアタッチされたEC2のIAM Roleから実行されたイベントであるためです。ちなみに派生後このIAM UserではAMIの共有が行われます。
一方作成されたEC2からは何でも出来るようになったので、RDSのスナップショットが共有されるところから始まります。
その後はEBS・S3・Redshiftも同じように漏洩していきます。あれよあれよ。
というわけで何が起きたかめっちゃわかりやすかったですね。本来であればこれを元に各種封じ込めやクレデンシャル削除などの対応を行います。
ちなみに直感的なフローで理解した後、テーブル表示に切り替えればそれぞれのイベントの一覧を確認できより理解を深めることができます。
この関連性の確認はDetectiveの場合、一つ一つのイベントやリソースからリンクをたどって確認していくことになり、まだまだ全容を掴むのには足りないのですが、CNPではそれが一発で掴むことができます。素晴らしい！
まとめ
Radware社のCloud Native Protectorを利用して実際にAWS環境上で攻撃を発生させて、インシデント調査での有用性を確認しました。
私が言いたいのはとにかく、これで調査の全容を理解できるのでめっちゃ捗る！ということです。AWSの機能であるGuardDutyやDetectiveももちろん非常に大事な機能でどちらも絶対に利用すべきですが、CNPは更に対応を加速させます！
Attack Simulationはコインマイニングのものもあるので、次はこれを試していきます。