この記事について
2023年5月17日に開催された、AWSセキュリティインシデント疑似体験GameDayに弊社SREチームで参加しました。本記事ではGameDayの内容とGameDayに参加したことで得られたものを紹介します。なお、今後の参加者の方にとってネタバレにならないように、あえて具体的に書かないようにしていますのでご了承ください。
イベント情報
タイトル：「ハッカーの手口を追跡せよ！セキュリティインシデント疑似体験GameDay」
詳細はこちらをご覧ください。
ゲームの特徴
参加者はチームを組んで、一連のミッションに取り組みます。各ミッションは複数のクイズで構成されており、クイズに正答することで得点を獲得し、点数がもっとも高いチームの勝利となります。ミッションが進むにしたがってクイズの難易度が上がっていき、解き進めることによってゲーム環境で発生したセキュリティインシデントの内容や影響範囲が明らかになっていきます。
参加者はクイズに解答するゲームポータルとログ分析を行うSIEM on Amazon OpenSearch(以下、SIEM on AOS)の２つの画面を使います。インシデント調査はSIEM on AOSに取り込まれた各種ログだけを頼りに実施します。実際にセキュリティインシデントが発生した際は、AWSマネジメントコンソールを始めとして、使用可能なすべての手段を用いて調査すると思いますが、調査手段をログに限定しているところがゲーム性を高めていると言えるでしょう。
幸い、本物のセキュリティインシデントを経験したことはないのですが、インシデント調査とは、すなわちログ分析なのかもしれません。
なお、SIEM on AOSとは以下で公開されているSIEMソリューションのことです。
ゲームに参加することで得られるもの
ゲーム参加後に弊社SREチーム内で実施した振り返りも踏まえて、得られるものをまとめてみます。
- AWS環境におけるセキュリティインシデント調査の基本を押さえられる
- SIEM on AOSの活用法が分かる
- 必要な準備ができているか見直すきっかけになる
AWS環境におけるセキュリティインシデント調査の基本
唐突ですが、あなたが運用しているAWSアカウントにおいてセキュリティインシデントが発生したらどのように対応すればよいか、具体的な対応手順をイメージできるでしょうか。また、あなたが思い浮かべたイメージはチームで共有されているでしょうか。そして、あなたが思い浮かべた対応手順を検証したことはあるでしょうか。
このような問いかけに答える責任があるが、自信をもってYesと答えられない方にとって、セキュリティインシデント疑似体験GameDayは非常に有益です。ゲームを通して、AWS環境におけるセキュリティインシデント調査の基本的な流れを学ぶことができますし、チームで参加すれば共有の手間も省くことができます。ネタバレを避けるため、調査方法の説明はできないので、次のGameDayにチームで参加してみてください。
SIEM on AOSの活用法
GameDay参加以前から弊社ではSIEM on AOSを利用していますが、ゲームに参加してはじめて知った機能がありました。それは、SIEM on AOSに取り込んだ各種ログを横断して検索するDiscoverという機能です。Discoverを使用すると、たとえば、あるIPアドレスが出現する行を複数のソースのログを対象に検索することができます。これは非常に便利で、Amazon AthenaでセキュリティログやCloudTrailログ、アクセスログに対して個別に発行していたクエリをいっぺんに発行できるようなものです。GuardDutyのログに記録されたIPアドレスを抽出条件として、CloudTrailのログや各種アクセスログから対象のIPが含まれる行を簡単に探し出すことができます。
画像はこちらからお借りしました。
SIEM on AOSにはAWSサービスごとに事前定義されたダッシュボードが存在していて、これがよくできているので満足してしまっていたのですが、インシデント調査においてはダッシュボードを使うよりDiscoverの方が適していると分かりました。
必要な準備ができているか見直すきっかけになる
セキュリティインシデントに対して必要な準備ができているか見直すきっかけになりました。参加者によって必要な準備は異なると思うので詳細に記載しませんが、見直しの観点は共有できると考えたので書いておきます。
- 発見的統制の観点
- 不審なアクションを検出・通知できるか
- 攻撃者の行動を記録できるか
- 効率よくインシデントの調査ができるか
- 予防的統制の観点
- セキュリティリスクとなる危険な設定を検出できるか
- 脆弱性を放置していないか
インシデントに対応する前提として、AWS環境における不審なアクションを検出・通知できなければいけません。GuardDutyを有効化しているだけでは不十分で、GuardDutyのイベントを見逃さないようにするための通知のしくみが必要です。Severityが低いイベントであっても、そのイベントが発生したという事実がCriticalであるイベント（たとえば、S3のブロックパブリックアクセスやサーバーアクセスログを無効化される）もあるので、Severityを問わずGuardDutyのイベントがほかの通知に紛れないようにしておくことが重要だと感じました。
インシデント対応にはできるだけ多くの情報が必要になるので、ログ記録の設定ができているかの確認もしておきたいです。ログ記録は有効化していたが、調査に役立つ情報を出力するには追加設定が必要だったという事態にならないように、各種ログのフィールドも事前に調べておくと安心です。
膨大なログから攻撃の痕跡を効率よく探し出すには、ログ調査のツールが不可欠です。S3やサーバーからローカルにログをダウンロードしてシェル芸で頑張るよりも、CloudWatchLogs InsightやAthenaのようなAWSのサービスを使いこなす方が調査効率がよいです。ランニング費用はかかりますが、SIEM on AOSを使えるようにしておくと、複数のログを横断した調査がしやすくなります。
また、今回のGameDayでは発見的統制の重要性だけでなく、予防的統制の重要性も実感できました。バックドアを作られてしまったらと思うと恐ろしかったです。当然ですが、攻撃を受けないことが一番ですので、攻撃の手がかりとなるような誤った設定がされたらすぐにSecurityHubで検出できるようにしておきたいです。コンピューティングサービス上のアプリケーションの脆弱性を利用した攻撃を受ける可能性もあるため、Amazon Inspector等で脆弱性を検出できるようにして、緊急度の高い脆弱性は速やかに修復したいものです。
これらすべてを実施するのはたいへんですが、インシデントが発生したときのために、そしてインシデントを発生させないように、必要な対策を講じたいです。
おわりに
弊社SREチームの最終順位は23位でした。50チーム以上が参加していたので、まずまずの順位かなと思いますが、これからも精進していきます。
Discussion