マルウェアは長い間、情報セキュリティに対する大きな脅威でした。この種の攻撃を分析して防御する方法はさまざまです。一般に、静的分析と動的分析の 2 つのアプローチがあります。
静的分析の目的は、ファイルまたはプロセス メモリ内の悪意のあるコンテンツのパターンを探すことです。これらは、文字列、エンコードまたは圧縮されたデータの断片、コンパイルされたコードのシーケンスなどです。個々のパターンを検索するだけでなく、これらのパターンと追加の条件 (署名の場所へのバインド、他の場所の相対距離のチェックなど) の組み合わせも検索できます。
動的分析とは、プログラムの動作を分析することです。プログラムはいわゆるエミュレーション モードで実行できることに注意してください。OS に損傷を与えることなく、アクションを安全に解釈できる必要があります。もう 1 つのオプションは、仮想環境 (サンドボックス) でプログラムを実行することです。この場合、システム上で公正な強制措置が実行され、通話が記録されます。記録される詳細レベルは、観察の深度と分析システムのパフォーマンスのバランスによって決まります。その出力は、オペレーティング システム上でのプログラムのアクションのログ (動作の追跡) であり、さらに分析することができます。
動的分析または動作分析の主な利点は、攻撃者がコードと悪意のある意図を難読化しようとしても、悪意のあるアクティビティがウイルス アナリストによって発見されることです。マルウェア検出タスクをアクション分析に削減することで、高度なマルウェア検出アルゴリズムの堅牢性についての仮定を立てることができます。さらに、分析環境の初期状態は同じであるため (仮想サーバーの状態キャスト)、動作の再現性により、正当な動作と悪意のある動作を分類するタスクが簡素化されます。
通常、行動分析へのアプローチはルール セットに基づいています。専門家の分析がシグネチャに反映され、それに基づいてマルウェアおよびファイル検出ツールが結論を導き出します。ただし、この場合には問題が発生します。書面化されたルールに厳密に従った攻撃のみがカウントされ、これらの条件を満たさないものの悪意のある攻撃は無視される可能性があります。同じマルウェアが変更されると、同じ問題が発生します。これは、よりソフトなトリガー基準を使用することで解決できます。つまり、一般的なルールをもう 1 つ作成するか、マルウェアごとに多数のルールを作成できます。前者のケースでは多くの誤検知が発生するリスクがありますが、後者のケースでは多大な時間が必要となり、必要な更新に遅れが生じる可能性があります。
私たちがすでに持っている知識を他の同様のケースにも拡張する必要があります。つまり、これまでに遭遇したことがないか、ルールに対処したことがないが、特定の特徴の類似性に基づいて、そのアクティビティが悪意のあるものである可能性があると結論付けることができるケースです。ここで機械学習アルゴリズムが活躍します。
ML モデルは、正しくトレーニングされていれば一般化可能です。これは、トレーニングされたモデルがトレーニングに使用されたすべてのサンプルを単に学習するのではなく、トレーニング サンプルのパターンに基づいて新しいサンプルについて決定できることを意味します。
ただし、一般化可能性を機能させるには、トレーニング段階で 2 つの主な要素を考慮する必要があります。
- 機能セットはできる限り完全である必要があります (モデルができるだけ多くのパターンを認識できるようにして、その知識を新しい例に拡張できるようにするため) が、冗長であってはなりません (有用な情報を持たないパターンを保存および処理しないようにするため)。モデルの特性)。
- データセットは代表的でバランスが取れており、定期的に更新される必要があります。
必要な量のデータを収集でき、機械学習によって既存のソリューションを拡張できるという前提があったため、この研究を行うことにしました。属性セットを生成し、それらに基づいてモデルをトレーニングし、属性に関するモデルを信頼するというものです。ファイルの悪意性 結論の正確さ。
専門知識を機械学習モデルに組み込む方法
マルウェア分析のコンテキストでは、生データはファイルそのものであり、中間データはファイルを生成する補助プロセスです。これらのプロセスは順番にシステム コールを実行します。これらの呼び出しシーケンスは、機能セットに変換する必要があるデータです。
データセットの作成は専門家側から始まります。専門家がマルウェア検出の観点から意味があると考える属性が選択されます。すべての属性は、システム コールを通じて n グラムの形式に復元できます。次に、モデルを使用して、どの属性が検出に最も寄与するかを推定し、冗長な属性を破棄し、データセットの最終バージョンを取得します。
ソースデータ:
{"カウント":1、"PID":"764"、"メソッド":"NtQuerySystemInformation"、"unixtime":"1639557419.628073"、"TID":"788"、"プラグイン":"syscall"、"PPID" :"416","その他":"REST: 、Module=\"nt\"、vCPU=1、CR3=0x174DB000、Syscall=51、NArgs=4、SystemInformationClass=0x53、SystemInformation=0x23BAD0、SystemInformationLength=0x10、ReturnLength =0x0","プロセス名":"windows\\system32\\svchost.exe"}
{"Key":"\\registry\\machine","GraphKey":"\\REGISTRY\\MACHINE","count":1,"plugin":"regmon","Method":"NtQueryKey"," unixtime":"1639557419.752278","TID":"3420","ProcessName":"users\\john\\desktop\\e95b20e76110cb9e3ecf0410441e40fd.exe","PPID":"1324","PID":"616"}
{"カウント":1、"PID":"616"、"メソッド":"NtQueryKey"、"unixtime":"1639557419.752278"、"TID":"3420"、"プラグイン":"syscall"、"PPID" :"1324","その他":"REST: 、Module=\"nt\"、vCPU=0、CR3=0x4B7BF000、Syscall=19、NArgs=5、KeyHandle=0x1F8、KeyInformationClass=0x7、KeyInformation=0x20CD88、長さ=0x4,ResultLength=0x20CD98","プロセス名":"users\\john\\desktop\\e95b20e76110cb9e3ecf0410441e40fd.exe"}
中間データ（シーケンス）：
syscall_NtQuerySystemInformation*regmon_NtQueryKey*syscall_NtQueryKey
モデルの知識がどのように蓄積されるのか、このプロセスはどのように変化するのか、そしてなぜデータの蓄積を適時に停止する必要があるのか
前述したように、データの基本的な要件は、代表性、バランス、定期的な更新です。悪意のあるファイルの動作分析における次の 3 つのポイントを明確にしましょう。
1. 表現。データの属性分布は現実の分布に近い必要があります。
2. バランス。モデルがトレーニングされる生データには「正当」または「悪意のある」というラベルが付けられ、この情報がモデルに渡されます。つまり、悪意のある例の数が純粋な例の数に近づくと問題が解決されます。
3. 定期的なアップデート。その多くは表現に関係しています。マルウェア ファイルの傾向は常に変化しているため、モデルの知識を定期的に更新する必要があります。
上記のすべての要件を考慮して、次のデータ蓄積プロセスが確立されました。
1. データは、メイン データ ストリームとリファレンス ケースの 2 つのタイプに分類されます。ベンチマークは専門家によって手動でチェックされ、そのマークアップの正確性が保証されています。ベンチマークを追加してモデルを検証し、トレーニング サンプルを管理する必要があります。メインラインはルールと自動チェックでマークされます。さまざまな実際の例を使用してサンプルを肉付けする必要があります。
2. すべてのベンチマークがトレーニング サンプルに直ちに追加されます。
3. さらに、プロセスからのいくつかの初期データセットがトレーニングに必要なデータ量に追加されます。ここで必要なデータ量は、(データの多様性の観点から) 十分に完全で代表的であることが証明されたトレーニング サンプルの数として理解されます。ベンチマークは専門家によって手動でテストされるため、ベンチマークから数万件だけを収集することは不可能であり、その結果、データ ストリームからのデータの種類が増加します。
4. 新しいデータ ストリームでモデルを定期的にテストします。
5. まず、ベンチマーク例の正確性を確保する必要があり、矛盾がある場合にはベンチマークデータが優先され、いかなる場合も保存されます。
時間の経過とともに、データ ストリームから十分なデータが蓄積されるため、より制御されたトレーニング サンプルを優先してエラーベースの自動蓄積を削除する必要があります。
1. これまでのところ、蓄積されたトレーニング サンプルは固定されています。
2. データ ストリームからのデータはモデルのテストにのみ使用され、トレーニング サンプルにはインスタンスは追加されません。
3. 参照インスタンス セットが更新された場合にのみ、トレーニング サンプルを更新できます。
したがって、次のことを達成することができました。
1. トレーニングおよび固定されたモデルがデータ ドリフトに対して十分に堅牢であることが検証されています。
2. トレーニング サンプルに追加された各新しいインスタンスを監視します (ベンチマークは専門家によって手動でチェックされます)。
3. すべての変更を追跡し、ベンチマーク データセットの精度を保証できます。
更新のたびにモデルの品質を確実に向上させる方法
上記のデータ蓄積プロセスの後、当然の疑問が生じるかもしれません。なぜ更新のたびにモデルが改善されると確信できるのでしょうか?
答えは依然として同じベンチマーク サンプルです。このサンプルの例は専門家によって手動でテストされ、フラグが付けられているため、これが最も正しいと信じています。更新するたびに最初に確認するのは、このサンプルの 100% の精度が引き続き保証されていることです。「実際に」実行されたテストにより、精度が向上していることが確認されました。
これは、トレーニング サンプルから一貫性のない参照データを除去することで実現されます。矛盾するデータとは、ベクトル距離がベースライン サンプルのトレースに十分近いものの、反対のラベルを持つストリームから蓄積されたサンプルを意味します。
私たちの実験では、ベンチマーク サンプルの精度を向上させるためにトレーニング サンプルからこれらの例を削除した後、データ フローの精度が向上するため、データ フローの観点から見てもそのような例は外れ値であることが示されています。
関連の形式でのMLメソッドと動作検出器の相補性
ML モデルは、相関の形式での動作検出と組み合わせると非常に優れたパフォーマンスを発揮します。類似および関連するものの検出によってソリューションをスケーリングする必要がある状況では、このモデルが適切に一般化されるため、このモデルが組み合わされることに注意することが重要です。標準条件でテストする場合には、このモデルは適用されません。
ML メソッドが実際にソリューションを拡張できる例は次のとおりです。
- 異常な子プロセスの連鎖。多数の分岐チェーンが存在すること自体は、正当な現象です。しかし、ノード数の異常、ネストのレベル、特定のプロセス名の反復または非反復はすべてモデルによって認識されるため、人々はそのようなものが悪意のあるものであることを事前に知ることを好みません。
- デフォルトの呼び出しパラメータの非標準値。ほとんどの場合、アナリストは意味のある関数パラメーターに興味を持ち、その中に悪意のあるものがないかを探します。他のパラメータ、つまり大まかに言えばデフォルト値は、実際には重要ではありません。しかし、ある時点でそれが発生し、たとえばデフォルトの 5 の代わりに 6 番目の値が表示されます。アナリストはそれが可能であるとは予想していなかったかもしれませんが、モデルはそれに気づいていました。
- 関数呼び出しの異常なシーケンス。これは、各機能が単独で悪意のある行為を行っていない状況です。また、何も悪意のある行為をしているわけではありません。しかし、たまたまそれらのシーケンスが正規のソフトウェアで見つからないことが起こります。アナリストがそのようなパターンを見つけるには膨大な経験が必要です。しかし、このモデルは (複数の) ことに気づき、実際には悪意の指標となることを意図していない特徴によって分類するという問題を解決しました。
シグネチャベースの行動分析は重要な例です。
- 悪意のある動作の 1 回の呼び出しによる特定のコンポーネントの使用。システムでは、さまざまな程度のバリエーションを持つ数百のオブジェクトが使用されます。他の 100 万個のオブジェクトを背景にした 1 つのオブジェクトの使用を捕捉する可能性は低く、異常の粒度は低いままです。
- プロアクティブな脅威モデルの検出。システム内の特定のオブジェクトに対する特定のアクションは、少なくとも 1 回は受け入れられないと決定します。初めてモデルがこれが重要な現象であることを理解していない可能性があるため、そのようなものの分類段階でエラーや不確実な決定が発生する可能性があります。
・一連の動作がぼやけてしまう。たとえば、3 ～ 4 つの動きを特定の順序で実行する必要があることがわかっている場合があります。間に何があるかは関係ありません。3 ～ 4 つの主要な動きの間にガベージな動きを入れると、モデルが混乱し、誤った決定を下すことになります。そして、特徴の数の次元により、呼び出しシーケンスの合計だけでなくすべての組み合わせを保存することでこの混乱を説明することは不可能になります。