SQLクエリによるインシデント調査

CloudTrailとFlow Logsをカタログ化すると、調査は何十億ものイベントを重要な少数に絞り込む一連のSQL queriesになります。重要なのは、何を問うべきかを知ることです。誰が、何を、どこから、いつ行ったのか。このレッスンでは、調査担当者が頼りにするクエリパターンを扱います。

認証情報の漏えいが疑われる場合は、そのprincipalによるすべてのアクションをクエリします。userIdentity.arnまたはアクセスキーIDでCloudTrailをフィルタリングすると、その認証情報が行ったすべてのAPI呼び出しを時系列で確認できます。この攻撃者の行動タイムラインは、多くの場合、調査で得られる最も価値の高い成果です。

sourceIPAddressでフィルタリングすると、特定のアドレスから行われたすべての操作を確認できます。GuardDutyの検出結果から不審なIPが1つ判明している場合、そのIPが各サービスで行ったすべての呼び出しを見つけ出せます。これにより、被害範囲を把握し、攻撃者が触れたリソースを特定できます。

errorCodeがAccessDeniedまたはUnauthorizedOperationであるイベントをクエリすると、偵察活動が明らかになります。これは、攻撃者が盗んだ認証情報で何ができるかを試している状態です。1つのプリンシパルから拒否が急増した後に成功した呼び出しが続く場合、攻撃者が使える権限を見つけたことを示しており、明確な権限昇格の兆候です。

CreateUser、AttachUserPolicy、CreateAccessKey、PutUserPolicyなど、機密性の高いIAMイベントを監視します。攻撃者は、新しいアイデンティティやキーを作成して永続化を試みることがよくあります。これらのイベント名をクエリすれば、初期侵入後に足場をさらに強固にしようとする試みをすばやく見つけられます。

強力な調査では、data sourcesを結合します。CloudTrailのプリンシパルによる操作を同じインスタンスのVPC Flow Logsや、そのインスタンスが処理したリクエストのALBログと照合する、といった方法です。コントロールプレーンのアクティビティとネットワークアクティビティを関連付けることで、断片的な情報ではなく、攻撃全体の経緯を再構成できます。

イベントのタイムスタンプを使い、必ずクエリをtime windowに絞り込みます。これにより調査対象の期間に集中でき、パーティションと組み合わせればスキャンするデータ量とコストを大幅に削減できます。最初は広い時間範囲から始め、状況が明らかになるにつれて絞り込むのが自然な進め方です。

集計によってパターンが見えてきます。たとえば、送信元IPでGROUP BYして通信量の多い送信元を見つけたり、プリンシパルごとにイベント名の種類数を数えて活動範囲を把握したり、時間ごとにエラーを集計して急増を見つけたりできます。こうした要約により、生の行データが、実際のインシデントを指し示す傾向に変わります。

同じSQLアプローチをS3のFlow Logsにも適用できます。大量の送信データを見つけたり、送信元ごとに拒否されたポート数を数えたり、インスタンスが通信した外部IPを一覧表示したりできます。CloudTrail（APIで何が行われたか）とFlow Logs（ネットワーク上で何が転送されたか）を組み合わせることで、全体像の両面を把握できます。

検証済みの調査用クエリはnamed queriesまたはビューとして保存し、次のインシデントでチームがすばやく再実行できるようにします。「アクセスキーによるすべてのアクション」や「過去1時間の拒否された呼び出し」のような検証済みクエリのライブラリがあれば、その場限りの作業を再現可能な対応能力へと変えられます。

クエリは証拠を生み、その証拠が対応を導きます。キーを無効化する、インスタンスを隔離する、不正なIAMユーザーを削除する、といった対応です。まずプリンシパル、次にIP、続いて権限昇格イベント、最後に相関分析という規律あるクエリの進め方により、インシデントを適切に封じ込めるために必要な、確信の持てる完全な状況把握が可能になります。

調査クエリに関する知識を確認しましょう。

調査とは、カタログ化されたログに対するSQL queriesです。まずprincipalまたはsource IPから始め、偵察活動を探すためにdenied callsをハンティングし、CreateAccessKeyなどのIAMイベントでescalationを監視し、すべてのクエリにtime-boundの条件を付けます。Group and countでパターンを見つけ、CloudTrailとFlow Logsをcorrelateし、検証済みのnamed queriesを保存することで、証拠収集を再現可能な対応能力に変えられます。