午前 3 時のアラートを読む：良いトリアージとは
成熟した SOC と高価なアラート転送サービスの違いは、インシデント発生後の最初の 4 分に表れます。その手順を示します。
SOC console, live detection view
Real console screenshot with a genuine timeline and alert queue, identifiers removed. Do not fabricate alert volumes.
2400×1350 · PNG · @2x
03:12、アラートが発報します。ありえない移動：同一アカウントが 11 分の間隔で、リッチモンドと他国のホスティング事業者の両方から認証されている。ここまではツールが教えてくれます。その後に何が起きるかは、完全に人とプロセス次第です。
1 分目 — これは本物か
ありえない移動は、現存する中でも最も騒がしい検知の一つです。VPN、社内プロキシ、別リージョン経由で通信する携帯キャリア、サービスアカウントで動くクラウド VM 上のスケジュールタスク。何をおいてもまず、アナリストは 2 番目の位置が説明可能かどうかを確かめます。「ありえない」区間があなた自身の出口レンジから来ているなら、それはインシデントではなく調整の問題です。
2 分目 — そのセッションは何をしたか
ほとんどのアラート転送サービスはここで止まり、本物の調査はここから始まります。ログインはインシデントではありません。ログインに続いて、すべてを外部アドレスへ転送し送信済みコピーを削除する受信トレイのルールが作られていれば、それはインシデントです。そして両者は別のログに存在します。
- 新しい受信トレイルールやメールフロールール、特に転送や自動削除
- 新しい場所から追加・変更・登録された多要素認証の方式
- OAuth アプリケーションへの同意付与
- 文書ストレージへの大量アクセスや大量ダウンロード
- 当該アカウントや他アカウントに対する権限変更
ログインはインシデントではありません。ログインに新しい転送ルールが加われば、それは 15 分先行された進行中の侵害です。
3 分目 — 動く前に範囲を見極める
本能は即座にアカウントを無効化することです。それが正しい場面もあります。しかし突然アクセスを失った攻撃者は、自分が見つかったと知ります。第二の足がかりを作っていたなら、それを使えと教えたことになります。そのアカウントだけが関与しているのかを確かめる 2 分は、たいてい価値のある 2 分です。そしてそれはプレイブックの分岐ではなく、アナリストの判断を要する問いです。
4 分目 — 封じ込め、それから人を起こす
パスワードだけでなく、セッションとリフレッシュトークンを失効させてください。リセットだけでは既存のトークンは期限まで有効です。悪意あるルールは記録してから削除します。そして電話をかけます。午前 3 時に、確かなアカウント侵害のために適切な人を起こすのは正しい判断です。誰かを煩わせたくないという理由でその電話を避ける SOC は、あなたが買ったサービスを提供していません。
翌朝に起きること
サービスとサブスクリプションを分けるのがこの部分です。検知が調整されます。アラートがノイズだったなら、同じ誤検知が二度と発報しないようルールを直します。本物だったなら、それを許した隙間——そのアカウントに条件付きアクセスがない、トークン保護がない、OAuth 同意にアラートがない——が、担当者付きの文書化された推奨事項になります。学びのないインシデントは、もう一度起きることを受け入れたインシデントです。