Twitter
Facebook
Hatena
セキュリティインシデント疑似体験 調査ワークショップに参加しました

クラウドアーキテクチャーエバンジェリスト兼IoTクラウド基盤アーキテクトの森⽥です。IoTやサーバーレスを活用したアマゾン ウェブ サービス(AWS)のアーキテクチャの検討、提案、構築を行っています。


AWSがAPN AWS Top Engineers限定特別セッションとして主催したセキュリティインシデント疑似体験 調査ワークショップに参加しました。セキュリティインシデントが発生した状態が提供され、出題される問題に回答するゲーム形式のイベントです。ゲームとしての面白さもありますが、トラブルシューティング力が試され技術者としてとても貴重な体験ができました

ワークショップ概要

日時:
2023年1月31日(火) 13:30-17:00(オンライン開催)

内容:
セキュリティインシデントが発生したら、何をすべきか、インシデント調査をどうしたら良いか等の悩みはありませんか?本ワークショップはAWS環境上の典型的なセキュリティインシデントを再現させたログを使用して、チーム対抗のCTF(クイズ)形式で開催します。参加によって一般的なインシデント調査の技術を習得できます。使用するツールはAmazon OpenSearch Serviceです。未経験者でも楽しんで参加できるように分析方法の簡単な説明も行います。
(参加募集案内より)

参加者

弊社からは北村安斎大槻、私を含め8名(4名×2チーム)で参加しました。

ワークショップの目的

ワークショップは、AWS上でセキュリティインシデントが発生したと仮定し、調査の疑似体験を行います。詳細は記載できませんが、IAM(Identity and Access Management)のアクセスキーが漏洩して不正に利用されていたり、Amazon EC2にバックドアが仕込まれていたりします。セキュリティ問題の発生経路や影響調査を実施しますが、参照できるのはログだけで、不正なユーザーの有無をAWS マネジメントコンソールで確認することはできません。
調査のステップごとに設問が用意されており、クリアするごとにポイントが加算され、回答を間違えた場合やヒントを使用すると減点されるため、楽しんで取り組むことができます。チーム戦ということもあり、担当分けも重要なポイントです。

SIEM on Amazon OpenSearch Serviceについて

ワークショップではSIEM on Amazon OpenSearch Serviceの環境を使用します。
SIEM on Amazon OpenSearch Serviceは、AWSサービスのセキュリティ監視をするためのスクリプトやダッシュボードのサンプルです。オープンソースで公開されており、なんと日本のソリューションアーキテクトの方々が中心となり開発されたとのことです。


SIEM on Amazon OpenSearch Serviceの特徴は以下の通り

  • AWS CloudFormation/CDKによるデプロイ(約30分で完了)
  • マネージドサービスとサーバーレスのみで構成
  • マルチアカウント/マルチリージョン対応
  • AWSサービス専用の正規化、ダッシュボード
  • Amazon Security LakeやAWS Control Towerと連携が可能
  • 複数のインテリジェンス情報(IoC)とマッチング

出典:ワークショップ時に配布された資料

SIEM on Amazon OpenSearch ServiceはAmazon S3のバケットに出力されたログを取り込む仕組みとなっています。AWSサービスのログをAmazon S3バケットに出力するには設定が必要ですが、ドキュメントに従って実施するだけで簡単に導入できます。

Amazon OpenSearch Dashboardsを使用したログ分析手法

ワークショップに取り組む前に、Amazon OpenSearch Dashboardsを使用したログ分析方法の解説がありました。Amazon OpenSearch DashboardsはAmazon OpenSearch Searviceに含まれるダッシュボードで、ブラウザ上で動作します。

ログはIndexという単位で保存され、どのIndexのログを表示するかを選択します。[log-*]を選択するとすべてのログが対象になります。

ログの表示期間を変更します。直近7日間等の相対指定だけでなく、2022年7月10日から2022年7月11日までといった絶対指定も可能です。

ログ分析には「抽出」「除外」「相関分析」のテクニックが重要です。一例として、抽出と相関分析を組み合わせて次のような分析が可能です。
まず、Amazon GuardDutyのログを表示します。怪しいIPアドレスを見つけたら、そのIPアドレスをフィルター条件に追加します。表示するログをAWS CloudTrailに切り替えます。フィルター条件を引き継いだままAWS CloudTrailのログが表示されるため、API操作ログの調査を継続することが可能です。

ワークショップの結果と感想

途中、AWS環境のアクシデントがあったため参考値という扱いですが、参加した30チームのうち18位という悔しい結果でした。APN AWS Top Engineersの皆様と競っているという点では健闘したと言えるかもしれません。

今回のワークショップでは、Amazon GuardDuty、AWS CloudTrail、AWS Security Hub、VPC フローログといったAWSサービスで取得できるログだけでなく、Amazon EC2のセキュリティログやWebサーバーのアクセスログも用意されていました。Amazon GuardDutyのログとAmazon EC2のログを組み合わせて調査するケースもあり、AWS以外のログも取得しておくことの重要性を学ぶことができました。

実際に発生しそうなケースが用意されていたので良い経験となりました。なかなか実案件では遭遇しない(遭遇したくない)状況ですし、貴重な訓練ができて有意義なワークショップでした。社内勉強会の題材としてもとても良いので、活用を検討したいと思います。


ワークショップの時間内には達成できませんでしたが、居残りして全ミッションをクリアしました!!

富士ソフトのAWS関連サービスについて、詳しくはこちら
アマゾンウェブサービス(AWS)

 

 

この記事の執筆者

森田 和明Kazuaki Morita

エリア事業本部
西日本支社
インテグレーション&ソリューション部
ITアーキテクトグループ
主任 / フェロー

AWS IoT クラウド アプリ開発