SIEM システムには、不審な動作を追跡するために専門家によって作成された多くのルールがあります。ただし、厳密なルールでは説明できないため、効果的に追跡できない攻撃シナリオも数多くあります。
SIEM システムが日常的に処理するデータの量と、(攻撃者の行動を発見する目的で) このデータを分析する特有の課題を考慮すると、今日の機械学習の適用は必要であり、非常に効果的です。
ミッションの詳細
この特定のケースでは、次の課題に対処しました。攻撃者は、IT インフラストラクチャへのアクセスを取得すると、さまざまな戦術やテクニックを使用して足場を築き、さらに前進します。攻撃者のすべての活動は何らかの形で痕跡を残し、その後攻撃者がその攻撃を見つけます。 SIEM システムに侵入します。
ほとんどの戦術の使用は、プロセスの開始に関連する Windows ログ イベント (Sysmon EventID 1 および Windows Security Event ID 4688) に記録されます。不要な情報は脇に置いて、初期データは次の表のように表すことができます。
| ユーザー名 |
プロセス名 |
| イワン・イワン |
cmd.exe |
| ペトロフ・ペトル |
Outlook.exe |
| シドロフ・ニコライ |
フーアミ.exe |
インフラストラクチャ内で実行されているすべてのプロセスとユーザーのリストが、どのアカウントで実行されているかを確認できます。どのプロセスが特定のユーザーにとって正常であり、どのプロセスが非定型、つまり異常であるかを認識するように SIEM システムを教えることが重要です。そして、おそらくご想像のとおり、あるユーザーにとっては異常なプロセスが、別のユーザーにとってはまったく正常に見える可能性があります。
この機能（ユーザーの異常なプロセスを検知する機能）により、多くの攻撃試みを早期に検知できるようになります。たとえば、2 つの状況を想像してください。会計士が自分のワークステーションでユーティリティを実行して Active Directory ドメイン サービス情報をクエリするのと、これまでオフィス ソフトウェアのみで仕事をしていた秘書が突然会計ソフトウェアを実行するというものです。それはおそらく何もないでしょう。会計士のコンピュータはネットワークの問題を診断するために座っているシステム管理者にすぎず、秘書は追加の任務を負っています。しかし、別の説明も考えられます。アカウントが侵入者によって乗っ取られ、昇進のためにスカウトされたのです。あるいは、この秘書は実は会社からデータベースを盗もうとしている内部関係者である可能性もあります。
このようなケースでは、特定のイベント トリガーとは関係なく、状況のコンテキストとサードパーティのイベントを考慮して、SIEM オペレーターの注意と詳細を確実に必要とします。
問題解決の基本的なアプローチ
この問題を解決するにはどのような方法がありますか? 最初に思い浮かぶのは、特定のユーザーによって開始されたすべてのプロセスを制御し、そのユーザーに対するアクセス許可を確認することです。
一見すると、このような単純なアルゴリズムで問題が解決されたように見えます。しかし、テストしてみると、次のような状況になりました。
私たちの組織に、お気に入りの IDE (Visual Studio Code) でコードを書くことを好むプログラマーがいると想像してください。ある日、友人が別のツールである PyCharm を試してみることを提案し、彼はそのアドバイスに従いました。私たちのアルゴリズムの観点から見ると、異常、非典型的な動作が存在します。当社のユーザーはこのプログラムで作業したことがありません。しかし、SIEM 運用者の観点から見ると、注意すべきことは何もありません。これは偽陽性、つまり偽陽性です。そして、そのようなケースはたくさんあるでしょう、それは私たちのアルゴリズムの有用性をゼロにします。
この問題をどうやって解決すればよいでしょうか? 具体的なアプリケーションではなく、その機能的な目的に基づいて運用してみようというアイデアがすぐに頭に浮かびました。すべてのアプリケーションを分類し、グループにまとめてみましょう。たとえば、PyCharm と Visual Studio Code は「開発者ツール」というグループに属し、Microsoft Word と Microsoft Excel は「Office プログラム」グループに属します。
ユーザー証明書についても同じことができます。私たちのシステムはユーザーを個人として扱うのではなく、一連の機能的な役割として扱います。たとえば、1 人は開発者でパートタイムのシステム管理者、もう 1 人は会計士です。そしてシステムは、開発者が開発ツールを使用しても問題ないこと、会計士が会計ソフトウェアを使用しても問題がないことを学習します。オフィスソフトを利用することも可能です。
このアプローチは機能しますが、残念ながら、IT 部門が従業員のリストとその責任を常に更新している企業でのみ機能します。さらに、ソフトウェア インベントリを追跡して更新する必要がありますが、多くの代理店がアドホックまたは自社開発のソフトウェアを使用しているため、これも課題です。
機械学習のアプローチ
したがって、標準的な厳密なアルゴリズムでは労力が多すぎると人々が判断した場合は、機械学習の「魔法」を使用する時が来ました。各ユーザーの機能的責任とそれぞれの特定のプログラムの目的を真に「理解」するアルゴリズムを適用する必要があります。
これは複雑に見えます。しかし、私たちのニーズは、レコメンダー システムと呼ばれるアルゴリズムのクラスによって完全に満たされることがわかりました。
レコメンダー システムは、製品やコンテンツをユーザーに推奨するために設計された機械学習アルゴリズムのクラスです。
ご想像のとおり、推奨システムは私たちの生活に浸透しています。新しいコンテンツでユーザーの注意を引き付けたいとき、または新製品の購入を推奨したいときは、常にアルゴリズムを使用します。
レコメンダ システムを構築するには 2 つの方法があります。
• コンテンツベース。
• 協調フィルタリング。
コンテンツベースの手法が機能するには追加情報が必要です。この場合、各製品またはユーザーを一連の属性で記述する必要があります。例えば、ユーザーが映画を選択する場合、ジャンル、主演俳優、公開年、製作国などが挙げられる。これまで見てきたように、このタイプのレコメンダー システムは、この特定のタスクにおける要件を満たしていません。
一方、協調フィルタリング技術は、ユーザーが特定の製品をどの程度気に入っているかに関する情報のみを使用します。すべての属性のデータを収集する必要はありません。
協調フィルタリングがどのように機能するかを詳しく見てみましょう。他のプレミアム製品を購入した少数のユーザーがプレミアム製品を購入したと想像してみましょう。これらの残りのユーザーに製品を推奨するのは理にかなっています。
同じ製品に同様の評価を与える人々は、同様の趣味や好みを持っていることは明らかです。逆もまた同様です。特定のユーザー グループがコンテンツを気に入っている場合、そのコンテンツはよく特徴付けられています。協調フィルタリングは、これらの単純な原則に基づいています。
モデルをトレーニングする際のタスクは、各ユーザーと製品のベクトルを取得することです。これらのベクトルを掛け合わせると、ユーザーが購入時に与えるであろう製品評価が得られます。
協調フィルタリング技術の原理。ここで、P は m×d 次元のユーザー ベクトル行列、Q は d×n 次元の積ベクトル行列です。
主な疑問は、ユーザーやコンテンツに関する情報がない場合、どのようにしてこれらのベクトルを作成するかということです。しかし、それは一見しただけです。私たちには彼らの評価履歴があり、それは私たちにとって十分です。
たとえば、交互最小二乗 (ALS) アルゴリズムを使用してこれを行うことができます。計算を深く掘り下げることなく、その仕組みを次のように説明できます。ユーザー ベクトルの行列を修正し、それを最適化し、コンテンツ行列を変更します。私たちは損失関数の導関数 (勾配) を取得し、勾配の反対方向、つまり私たちが望む方向、つまり「真実」が存在する方向に移動します。私たちの予測は間違っているはずがありません。次に、コンテンツ マトリックスを修正し、ユーザー マトリックスに対しても同じことを行います。何度も繰り返し、目的の値に一歩ずつ近づき、モデルを「トレーニング」します。
このようにして、必要なベクトルを取得します。もちろん、具体的なベクトルをとってしまうと、人間の視点からは何も理解できなくなります。私たちにとって、それは単なる数字の集合にすぎません。ただし、このベクトル内の各数値とそれらの数値間の相対位置は意味があり、実際の状況を反映しています。
当然の疑問が生じます: レコメンダー システムを使用して異常を特定するにはどうすればよいでしょうか?
ユーザーがプロセスを実行すると、そのプロセスが気に入られるのは当然です。推薦システムの観点から言えば、このプロセスのスコアは高くなります。
逆も同様です。プロセスが異常である場合、この特定のユーザーおよび他の同様のユーザーがこれまたはそのプロセスを実行したことがない場合、推奨システムは低いスコアを与えます。つまり、ユーザーはプロセスが気に入らなかったと表示されます。 。つまり、（推奨システムによると）すべきではないにもかかわらず、自分が好きなことを始めるのです。これは異常値です。
このアプローチはテスト中にうまく機能することが証明されました。ユーザー ベクトルはユーザーの機能的責任をうまく記述するのに対し、アプリケーション ベクトルはアプリの機能セットをうまく記述することがわかりました。次の例でわかるように、ユーザー ベクトルは現実をよく反映しています。
すべてのユーザー ベクトルを 2 次元空間に反映させてみましょう。このような写真が得られます。
ユーザーアカウントの2D表示
ドットは特定のユーザーを表し、ドットの色はそのユーザーの職務上の責任を表し、スタッフ配置テーブルから抽出されます。同じ部門のユーザーが並べてグループ化されていることがわかります。これは、モデルが十分にトレーニングされており、内部状態が現実を反映していることを意味します。もちろん、この場合には例外もありますが、それらは特定の人の特定の行動に関連しています。
注目すべきもう 1 つの重要な視点機能は、このグラフ上の点 (ユーザー) の動きです。ユーザーがほぼ同じアクティビティに従事している場合、ユーザーは空間内の同じ位置にいることになります。ただし、彼のアカウントで非定型的な活動が開始された場合、ポイントの急激な「ジャンプ」が見られるでしょう。このような「ジャンプ」を検出して分析する便利なツールを作成すると、オペレーターを保護するのに役立ちます。
ここで、モデルの従来の使用法が実際にどのようなものになるかを見てみましょう。
ユーザーのモデル予測の時系列
このグラフは、特定のユーザーのモデルの測定値をプロットします。Y 軸の数値が小さいほど、ユーザーの動作は「正常」ではなくなります。7 月 7 日以前は、このユーザーの行動には何も異常はなく、異常値が 0.9 を下回ることはありませんでした。しかし、7 月 11 日、侵入者がアカウントを乗っ取り、モデルは低い値を生成し始めました。
結論は
この実験では、インフラの偵察を行うためにユーティリティが使用されました。これは確かにユーザーの典型的な行動ではありません。シンプルで基本的なリファラー システムを適用しました。このアイデアをさらに発展させるために、コンテンツベースの協調フィルタリングを使用した共同推奨システムの方向に進むことができ、また深層学習システムを実装することもできます。私たちの実験から得られた主な結論は、レコメンダー システムを使用して異常を見つけることは、幅広いサイバーセキュリティ問題の解決に役立つ大きな可能性があるということです。