2023年7月21日

NECサイバーセキュリティ戦略統括部セキュリティ技術センターの中野です。本ブログでは、AWSのセキュリティイベントシミュレーションツールであるAWS CloudSagaをご紹介いたします。AWS CloudSagaを使用することで、AWS環境のセキュリティ制御やアラートの設定をテストすることができます。AWS環境のテストにご興味がある方は、ぜひ本ブログをご一読ください。

AWS CloudSagaとは

AWS CloudSaga [1]はAWS上でセキュリティイベントをシミュレーションできるツールで、AWS 公式からOSSとして公開されています。AWS CloudSagaではAWS上でよく見られる攻撃手順を模したシナリオがいくつか用意されており、そのシナリオに沿ったセキュリティイベントを疑似体験できます。これにより、攻撃が行われた際に正しくアラートが発生するか、メール通知が送信されるかなどをテストできます。用意されているシナリオには、ビットコインのマイニングツールを動かされる、VPCやセキュリティグループなどのネットワーク設定を変更される、といったものがあります。
なお、本ツールを使用してテストを実施する際、ツールにより実際に脆弱な設定に変更される、脆弱なリソースが作成されるということはありません。これは、本ツールがAWS CLIを用いてシミュレーションを行う際に、「DryRun」オプションを使用しているためです。DryRunオプションは、AWSリソースを操作する際に、実際にはリクエストを行わずにアクションに必要な権限があるか否かを確認し、エラー応答を返す機能です（[2]参照）。そのため、セキュリティリスクのあるアクションについては、ログには残るものの、実際には行われないといったことを本ツールは可能にしています。これにより、AWS上でセキュリティリスクのある設定変更やリソース作成をされてしまうことに抵抗がある方でも、安心してテストを実施することができます。

事前準備

事前準備は非常に簡単です。本ツールはAWS CloudShellまたはローカル環境で使用することができます。公式の説明 [1]によると、CloudShellでの使用が推奨されているため、今回はCloudShellで実行してみます。
まずはCloudShellを起動します。AWSにログインした後、検索バーの横にあるCloudShellのボタン（図1の赤枠部分）をクリックすることで、CloudShellを起動できます。

CloudShellのセッションが開始されたら、以下のコマンドを使用して、AWS CloudSagaをインストールします（図2）。
>　pip3 install cloudsaga

これでインストールは完了です。では、AWS CloudSagaの使い方を調べるために、以下のコマンドを打ってヘルプページを確認してみます（図3）。
>　cloudsaga -h

AWS CloudSagaで使用できるオプションの一覧が表示されます。--chaptersオプションでシミュレーションできるシナリオの一覧を確認、--aboutオプションでそのシナリオの詳細を確認でき、--scenarioオプションで実際にシナリオをシミュレーションできるようです。
--chaptersオプションを使用してAWS CloudSagaで実行できるシナリオの一覧を確認してみます（図4）。

ビットコインのマイニングツール実行（mining-bitcoin）やネットワーク設定の変更(network-changes)といったシナリオがあることが確認できます。

ネットワーク設定の変更

では、試しにネットワーク設定変更のシナリオを実行してみます。
まずは--aboutオプションでシナリオの詳細を確認してみます（図5）。

説明文から、このシナリオはVPCの作成やセキュリティグループの変更を行うことが分かります。攻撃者がAWS環境上のリソースに侵入する際、ネットワークの設定変更を行うことを想定しているようです。これだけだと具体的な動作が分かりにくいため、ソースコード [1]の方も見てみました。どうやらこちらのシナリオは以下の3ステップで動作するようです。

では、こちらのシナリオを--scenarioオプションで実行してみます（図6）。

大量のログが出てきますが、まずはステップ①の通りEC2インスタンスが存在しないリージョンを探しているようです。その際、EC2.DescribeInstancesのAPI Callを発行していることが分かります。
しばらくログを見ていくと、ステップ②に入り、EC2インスタンスが存在しなかったリージョンにVPCを作成していることが分かります。なお、DryRunオプションが付与されているため実際にVPCが作成されることはなく、エラーが返ってきています（図7）。

さらにログを見ていくと、ステップ③に入り、今度はEC2インスタンスが存在するリージョンでセキュリティグループを作成していることが分かります。こちらもステップ②と同じくDryRunオプションが付与されているため、実際にセキュリティグループが作成されることなく、エラーが返ってきています（図8）。

ログやアラートの確認

現状のセキュリティ設定で問題がないかを確認するために、シナリオ実行によってアラートが発生しているか、ログとして記録されているかをAWS環境上で確認します。
まずは、Amazon GuardDutyでアラートが発生していないかを確認します。AWSには、Amazon GuardDutyという脅威検出サービスがあり、AWS上で不審な動作が確認されるとAmazon GuardDutyでアラートが発生するようになっています。さっそくAWSにログインしてAmazon GuardDutyを確認してみましたが、本シナリオ実行によるアラートは発生していませんでした。Amazon GuardDutyは機械学習を使用して脅威となるか否かを判断します。今回はDryRunで実行したこともあり、脅威と判断されなかったのかもしれません。
次に、AWS CloudTrailを確認してみました。AWS上での操作は基本的にAWS CloudTrailにログとして記録されます。AWS CloudTrailを確認してみたところ、シナリオ実行によるログが確認できました（図9）。

設定の改善

AWS環境で確認した結果、ログとして記録されたもののアラートは発生しなかったという問題があることが分かりました。せっかくなので、この問題を解決するために、設定の改善を行いたいと思います。今回は、セキュリティグループが新規作成された際に、メール通知が送信されるよう設定変更を行いました。手順は以下です。

詳細な設定方法はここでは省きますが、ご興味のある方はEventBridge ルール作成の例 [3]などを参考に実施してみてください。
設定を改善した後、再度シナリオを実行すると、セキュリティグループが作成されたというメール通知が届きました（図10）。

今回はセキュリティグループの新規作成をトリガーにしましたが、セキュリティグループを日頃から新規作成するような運用をされている場合は、平常時でもメール通知が送信されてしまうため、アラートの設定として好ましくありません。そのような場合は別の解決策を検討してみましょう。

まとめ

本ブログでは、AWSのセキュリティイベントシミュレーションツールであるAWS CloudSagaを紹介しました。AWS CloudSagaを使用することで、AWS環境内のセキュリティ制御やアラートの設定をテストすることができます。また、インシデント発生時の対応をシミュレーションする場合にも本ツールを活用できると思いました。自身でAWS環境を管理している方は、設定やインシデント対応手順の見直しにAWS CloudSagaを活用してみてはいかがでしょうか。

参考資料

執筆者の他の記事を読む