朝コーヒーを飲む前の重大なアラート
午前6時45分。 目覚ましが鳴り、夜明けのインクのような灰色に覆われた寝室のベットから飛び起きます。 最初に行うことは、携帯電話の通知を確認することです。すると P0 アラートが検知されています。あなたの前にシフトを担当していた EMEA ベースのアナリスト、ダニーはすでにログオフしています。 ダニーは両親が訪ねてきているところなので、今回は責めないことにします。あなたは朝のルーティンを急いで済ませ、コーヒーは諦めることにしました。P0 アラートはあまりにも頻繁に発生することからコーヒー無しの頭でも対応できるはずです。
P0 アラートを含む電子メール通知は、割り当てられた地理的地域と所有権領域 (EDR) 内に収まるため、自分自身に割り当てます。 重要なアラートに関しては時間が非常に重要であるため、すぐに次のステップである調査に進みます。 検知元のプラットフォーム上で利用可能なツールを使用して、ログを確認し、セキュリティ脅威の調査に対する 3 つの主要な質問 (1) 誰がそれを行ったのか、(2) 何をしたのか、(3) なぜアラートを受け取ったのか、ということを頭の中で答えてみます。
約 45 分後、複数のツールをめくってログの多くの行をスクロールすると、この検知は真陽性ではあるが良性であることが確認できます。 不審なアクティビティがありましたが、悪意のあるものではありませんでした。 キューから検知を削除し、このアラートに関するレポートを作成するためのメモを作成します。
時計を見ると、午前7時42分です。やっとコーヒーの時間です。午前 8 時のスタンドアップ ミーティングに間に合います。 キュー内の他の 10 個の検知について積極的に考えることはありません。
「オオカミがいる」と叫んだ検知は、実はオオカミだった
1週間後、気分は良くなりました。 圧倒的な数のアラートが受信されているにもかかわらず、ある程度の調子は整っています。 あなたはシフト内のすべての優先アラートにアクセスし、継続的に届く無害な肯定的なアラートの通知を受け取ることを避けるために、いくつかのきれいできちんとしたルールを作成しました。 いつもは厳しいマネージャーでさえ、真のポジティブなパターンを把握し、全員の負担を軽減するための恒久的なソリューションを導入したことに対して、あなたを事実上褒めてくれました。
SOC スプリントが成功した余韻に浸り、サンドイッチを交互に食べたり、検知を調査するためにログをスクロールしたりするだけの昼食を楽しんでいるときでも、何かがおかしいと感じます。 もしかしたら、P1 アラートを見逃したのかもしれません。いいえ、同僚がそれについてping を送っているはずですから、違います。もしかしたらコーヒーメーカーをつけたままにしてしまったのかもしれないと思い確認しますが、ちゃんとオフになっています。
静かです。アラート キューには一連の検知がありますが、それらは優先事項ではないため、昼食を終えた後に取り組むことができます。 目に見える警報や赤い旗はありません。静かです......。静かなことが気になります。
1 時間後、キュー内の検知を次々と実行しています。 それらのほとんどすべては悪意のあるものではありません。 どんどんクローズするのは気持ちの良いものです。 ブラウザーで更新をクリックし、座って UI バッファーとレンダリングを観察します。 こんな日は、早めに切り上げるのもいいかもしれません。 もしかしたら、数か月前に登録したものの、行く時間が見つからなかったジムへやっと行くのもいいかもしれません。
UIが更新されました。すると、優先度の高い多数の検知を示す赤いバナーがずらりと並んでいます。いったい何が起こったのでしょうか？
チーム チャットでうるさく通知が鳴っています。 何が起こっているのか、なぜプラットフォームに優先度の高いアラートが突然殺到したのか、誰も理解していません。 あなた自身を含め、誰もがパニック状態です。 それぞれの検知をクリックすると、多くのログに見覚えがあります。 ID、デバイス、オペレーティングシステム、すべてが見覚えのあるものです。 しかし、それらをブロックするために作成したルールは機能していません。その理由は、ルールはそれぞれ独自に当てはめていますが、今回の検知は全てを１つにまとめた脅威だったのです。
それはすべて、ビジネスを壊滅させる大規模なセキュリティ攻撃に発展しました。
何が問題だったのか
対応と修復のために何日も続けて取り組んだ結果、あなたとチームは、攻撃によるこれ以上の被害を阻止しました。ビジネス面では何も妥協することがなく、これは誰が見ても勝利です。しかし、それはストレスが多く、圧倒されっぱなしでした。一体何が問題だったのでしょうか?
あなたはまず、検知結果を良性陽性とラベル付けする可能性がある自分を責めますが、その作業はチームの他の 2 人によってチェックされ、検証されていました。 戻ってきたら良性の陽性反応が出たので、それに応じて対処されました。 そうすると、次はプラットフォームのせいにすることになります。 アルゴリズムやレポートに何らかの問題があり、仕事を正しく行うことができませんでしたが、それをスケープゴートとして利用しているだけであることはわかります。
過去 3 日間の作業で発生したイベントとデータを精査し、事後レポートを作成すると、検知がどのように統合攻撃に集中するかに気づき、攻撃の原因が自分やプラットフォームではないことに気づきます。 方向の誤りと混乱。 問題は検知自体にあります。
検知は、特にサイロ化されたものやさまざまなアタックサーフェイから頻繁に行われます。 通常、さまざまなアタックサーフェイスから情報を取り込む 1 つのプラットフォームに最も多くの時間を費やしますが、情報が膨大であるため、最終的にはそれらのツールに移行することになります。 問題は検知数にあります。検知数が多すぎて、その多くは優先度が低いため、必要なほど注意を払うことができませんでした。
しかし、どうやって知ることができたのでしょうか？ それらは軽微なものとみなされ、あなたには他にやるべきことがあったのです。では、このジレンマを解決できるものは何でしょうか?
全体像
アラートと検知は全体像を見逃しています。つまり、攻撃者は賢くて順応性があり、ある場所から別の場所へ飛び回り、カバレッジのギャップや安全でないバックドアを利用し、本格的な攻撃に向けて必要な情報をすべて収集する前に、やや危険な検知を装うだけであるということです。
ここで、エンティティベースの優先順位付けが問題を解決できます。 エンティティはアラートや検知ではありません。 これは、単一のエンティティに分類される、相関関係にあるイベントの累積です。 場合によっては、ホスト、アカウント、検知が含まれます。 エンティティを使用すると、アナリストは全体像を把握し、長期戦を繰り広げている攻撃者を捕まえることができます。
SOC アナリストとして、すべてを間違っていたかもしれませんが、それはあなたのせいではありません。テクノロジーが、アラートや検知よりもエンティティを優先するタイプの優先順位付けを採用すると、監視および対応するアラートが少なくなるだけでなく、より多くの真陽性をより迅速かつ確実に検知できるようになります。
そして最も重要なことは、朝、コーヒー時間を確実に確保できることです。