この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさん、こんにちは。
AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)です。
2022年に表彰されたAWS Top Enginner向けに『セキュリティインシデント疑似体験調査ワークショップ』というイベントが開催されました。
私は2022年のTop Enginnerの受賞は惜しくも(?)逃してしまったのですが、ありがたいことに弊社には多数の受賞者がおりそのうちの1名であるYoichi Saiに誘っていただいたことでイベントに参加できました。（崔さんありがとうございました！！！！）
※クローズドなイベントですが、AWSJの方からイベント内容のブログ執筆の許可をいただいております。
前置きはここまでにして、本題に移ります。
セキュリティインシデント疑似体験調査ワークショップとは
概要
セキュリティインシデントが発生したら、何をすべきか、インシデント調査をどうしたら良いかの悩みはありませんか？本ワークショップではAWS環境上の典型的なセキュリティインシデントを再現させたログを使って、チーム対抗のCTF(クイズ)形式で開催します。参加によって一般的なインシデント調査の技術を習得できます。使用するツールはAmazon OpenSearch Serviceです。未経験者でも楽しんで参加できるように分析方法の簡単な説明も行います。
本イベントはSIEM on Amazon Opensearch ServiceというAWSが公開しているソリューションを利用したログ分析基盤が事前に構築された環境で擬似的に発生させられたセキュリティインシデントを調査するワークショップとなっています。
SIEM on Amazon Opensearch Serviceについては以下ブログが参考になります。
ワークショップの目的・ゴール
こちらの4つです
- ワークショップを楽しむ
- AWS 環境で発生する典型的なセキュリティインシデントを知る
- 発見的統制とセキュリティ調査を疑似体験して重要性を理解する
- (OpenSearch Dashboards による)ログ調査ができるようになる
チームの構成
AWS Top Enginnerの代表者を中心に1名〜4名のメンバーでチームが編成されており、計35チームが参加していました。
今回はAWS Top Enginner向けのイベントだったため、チーム内に1名以上Top Enginnerがいることが必須でしたが、その他のチームメンバーはAWS Partner Network (APN)に参加している会社に所属しているAWSエンジニアという縛りのみでしたので、私も参加できました。
イベントの難易度
イベントの難易度は中級者（目安：Associateレベルの資格保持者）とされていました。
冒頭の説明でOpensearch ServiceのWebコンソールの基本的な使い方や代表的なログ分析の方法については説明がありましたが、ハンズオンのようなイベントとは異なり詳細な手順書のようなものはないため、初心者が参加すると少し大変そうな印象です。
ちなみに私は普段の業務ではAmazon Opensearch Serviceはほとんど取り扱わない上、疑似的なものも含めてAWS上でのセキュリティインシデントを対応する機会もこれまでありませんでした。最初こそ戸惑いましたがだんだん慣れてきてその後は問題なく進められたため、AWSの基本的な知識がある方なら問題ないと思われます。
ワークショップの内容
以下のようなイベント用のポータルサイトが準備されており、チーム単位でミッションに挑みます。
ミッションは「Level 0」「Level 1」「Level 2」とあり、Level 0はAWSに関するトリビアについての問題（例: 〜というAWSサービスの正式名称は？）やSIEMを利用して調べる基礎的な設問（例: 2022年のGuardDutyログの件数を答えなさい）、Level1,2が本題のセキュリティインシデント調査を行う設問となっています。
セキュリティインシデント調査はLevel 0のSIEMの基礎的な設問と実施する作業内容は似ているのですが、具体的なストーリーに沿って段階的なセキュリティインシデント調査を擬似体験できる設問となっています。
難易度は高いのですがより実践的なものを求められるため、かなり勉強になりました。
先述したイベントの概要やゴールにも記載がありますが、今回のワークショップのメインはAmazon Opensearch ServiceのDashboardを利用したセキュリティインシデントの調査、となります。
調査に利用したDashboardがこちらです。
得られた経験と感想
1. Opensearch Serviceでログを表示するための基本的な操作を「完全に理解した」
ワークショップの時間内のほとんど（体感8割）占めていたのがOpensearch Service Dashboardを利用したログの調査でした。 例えば、あらかじめ設定されているINDEX PATTERNを変更して調査するログを切り替えたり、分析するログの時間帯を変更したり、表示させるフィールドを変更したりと基本的な操作は「完全に理解した」と言ってしまってもいいでしょう。
Opensearch Service Dashboardを利用するとフィールド単位の抽出・除外がワンクリックでできたり、ログの切り替えも簡単なので個人的にはログ分析ガンガンやるならこれ一択だな、とつい思ってしまいました。
2. ログ分析のテクニックを学べた
冒頭でAWSJの方から、ログ分析において一番大切なことを教わりました。 それは「ログの抽出・除外」です。
大量のログの中から必要な情報にアクセスするためにログの抽出・除外をガンガンやっていく必要があります（前述していますがOpensearch Serviceだと超簡単です） 時にはアクセス元のSourceIPだったり、CloudTrailのイベントソースだったり、APIの実行元のユーザー名だったりします。
ただ、ログの抽出・除外の判断するためには「正しいアクセスを行っているリソースの情報」が何かを事前に知っている必要があります。 例えば、アクセス元の拠点のIPアドレス範囲、運用で利用しているEC2インスタンスのIPアドレスやリソースIDのようなものです。 正しいアクセスが何かを知らないと不正なものが判断できないのは言ってしまえば当然なのですが、疎かになってしまう時もあるかもしれません。セキュリティインシデントは突然発生するものなので事前にそう言った情報にすぐアクセスできるように普段から準備しておかないとな、と気付かされました。
3. AWSのセキュリティサービスの重要性とログ取得の大切さを再確認できた
GuardDutyはセキュリティインシデント発生時を知るきっかけになるサービスですが、それだけでなくGuardDutyで検知したログの内容（例: IAMアクセスキー、検知したサービス）はログ分析の起点になります。確実にあたりをつけられるため、インシデントの原因調査が捗りました。 Security Hubで各種サービスのアラート通知（例： GuardDutyのアラート、Macieによる機微情報の検知アラート）をまとめられていたおかげで各サービスのアラートログへのアクセスが迅速に行えました。「ログどこにある？→Security Hubを見よう」と解決できるのは楽ですね。Security Hubは3rd Party製品とも統合できるのでログの一元化がさらに捗りそうです。
万が一のためにセキュリティ系サービスは有効化しておかないとな、と実感できました。
そして、当たり前の話なのですが、そもそもログを取っておかないとログを使ったインシデント調査はできません。 「取れるログは全部取っておけ」と昔誰かに言われたのですが、ログ全部は全部取るんだぞ！！！絶対だぞ！！！と再認識できました。
最後に
今回はクローズドなイベントとして開催されましたが、評判次第で今後の一般公開も検討しているとのことでした。
本エントリを見て『セキュリティインシデント疑似体験調査ワークショップ』に興味を持ったそこのあなた。是非ともお近くのAWSJやAPNパートナーの担当までお声かけください。
以上、AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)でした。
26
