異常検出のための機能を準備/構築する方法（ネットワークセキュリティデータ）

私の目標は、侵入検出の目的でクラスタリング/異常検出を使用して、ネットワークログ（Apache、syslog、Active Directoryセキュリティ監査など）を分析することです。

ログから、IPアドレス、ユーザー名、ホスト名、宛先ポート、送信元ポートなどのテキストフィールドがたくさんあります（合計15〜20フィールド）。ログに攻撃があるかどうかはわかりませんが、最も疑わしいイベント（異常値）を強調表示したいと思います。

通常、異常検出は、確率/頻度が低いポイントを異常としてマークします。ただし、ログレコードの半分には、フィールドの一意の組み合わせが含まれています。したがって、データセット内のレコードの半分は、可能な限り低い頻度になります。

クラスタリングに基づく異常検出を使用する場合（たとえば、クラスタを見つけてから、すべてのクラスタの中心から離れているポイントを選択する）、異なるポイント間の距離を見つける必要があります。私は15〜20個のフィールドを持っているので、ユーザー名、ポート、IPアドレスなどの次元の多次元スペースになります。ただし、マハラノビス距離は正規分布の特徴にのみ適用できます。これは、データポイント間の距離を見つけてクラスターを構築する方法がないことを意味します...

たとえば、20レコードのデータセットに、ユーザーAlice、Bob、Carol、Dave、Eve、Frankがいるとします。それらは、データベース内で次の数の発生を持つ可能性があります：2,5,2,5,1,5。ユーザー名を数字に単にマッピングする場合、例えば

Alice --> 1
Bob --> 2
Carol --> 3
Dave --> 4
Eve --> 5
Frank --> 6

次に、ユーザー名の確率分布は次のようになります。

p（1）= 0.1、p（2）= 0.25、p（3）= 0.1、p（4）= 0.25、p（5）= 0.05、p（6）= 0.25

もちろん、これは正規分布ではなく、ユーザー名を別の方法でマッピングできるため、これもあまり意味がありません...

したがって、ユーザー名、アクション、ポート番号、IPアドレスなどのフィールドを番号に単純にマッピングしても、何も起こりません。

したがって、教師なしの異常/外れ値の検出を可能にするために、テキストフィールドがどのように処理/機能が通常構築されるかについてお聞きしたいと思います。

編集：データ構造。

データベーステーブルに約100列あり、Active Directoryイベントからの情報が含まれています。この100列から（私の観点から）最も重要なのは、SubjectUser、TargetUser、SourceIPaddress、SourceHostName、SourcePort、Computer、DestinationIPaddress、DestinationHostName、DestinationPort、Action、Status、FilePath、EventID、WeekDay、DayTimeです。

イベントはActive Directoryイベントであり、EventIDはログに記録されたもの（たとえば、Kerberosチケットの作成、ユーザーログオン、ユーザーログオフなど）を定義します。

データサンプルは次のようになります。

+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | Computer | DestinationIPaddress | DestinationHostName | DestinationPort | Action | Status | FilePath | EventID | WeekDay | DayTime |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 171390673 |？|？|？|？|？| domaincontroller1.domain.com | 1.1.1.1 | domaincontroller1.domain.com |？| / Authentication / Verify | / Success |？| 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 173348232 |？|？|？|？|？| domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |？| / Authentication / Verify | / Success |？| 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 180176916 |？|？|？|？|？| domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |？| / Authentication / Verify | / Success |？| 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+
| 144144725 |？| John.Doe | 3.3.3.3 | domaincontroller3.domain.com | 2407 | domaincontroller3.domain.com | 3.3.3.4 | domaincontroller3.domain.com |？| / Authentication / Verify | / Success |？| 4624 | 3 | 12345 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -+

全部で1億5,000万のイベントがあります。異なるイベントには異なるフィールドが入力されており、すべてのイベントがユーザーのログオン/ログオフに関連しているわけではありません。

私は間違いなく異常検出の専門家ではありません。しかし、それは興味深い領域であり、ここに私の2セントがあります。まず、「マハラノビス距離は正規分布の特徴にのみ適用できる」というメモを検討してください。私はいくつかの調査に出くわし、通常ではないデータの場合でもその測定基準を使用することがまだ可能であると主張しています。で、自分自身のために見てください、この論文および技術報告を。

私はまた、あなたが便利以下見つけることを期待していたリソースを上教師なし異常検知（AD）にITネットワークのセキュリティコンテキスト：様々なアプローチや方法を使用して、この論文を提示し、幾何学的な枠組み教師なしADのために、このペーパーでは、密度ベースおよびグリッドベースのクラスタリングアプローチを使用しています。このプレゼンテーションスライドでは、ADの自己組織化マップの使用について説明しています。

最後に、このトピックに関連していると思われる次の私の回答を見てみることをお勧めします。したがって、役立つかもしれません。クラスタリングアプローチに関する回答、非距離ベースのクラスタリングに関する回答、およびAD。

まず、辞任しなければならないことがいくつかあると思います。

この問題について私が見ている厳しい制約の1つは、おそらくかなり高い偽陽性率を準備する必要があるということです。私の知る限り、ネットワーク異常の一部であるレコードの基本レートは非常に低くなっています（引用が必要です）。議論のために、1000：1オッズと呼びましょう。次に、レコードが侵入の場合に発生する可能性が100倍高いパターンを観察した場合でも、それが合法である場合、ベイズのルールは、事後確率が10：1であり、トラフィックが合法であることを示しています。

もう一つの問題は、いくつかの侵入は原理的にさえ検出するのが難しいということです。たとえば、誰かが私にコンピューターを提供するようにソーシャルエンジニアリングを行った後、彼らがこのサービスにログインし、私が取り組んでいた1つの極秘ファイルをダウンロードした場合、これを見つけるのは非常に困難です。基本的に、十分に決定された攻撃者は、侵入動作をシステムの通常の動作にほぼ任意に近づけることができます。

さらに、敵対者は統計的プロセスではなくインテリジェントであるため、何らかのパターンを検出して遮断すると、そのパターンに従わなくなるだけで相手が反応する可能性があります。これが、たとえば、すべての文字の間にスペースが入った多数のスパムメッセージが表示される理由です（「V I A G R A」などを提供します）。スパムフィルターは、文字列 "viagra"がスパム行為をしていることを突き止めたので、攻撃者は別のことをし始めました。

このため、検出できるように努力する価値があると考える信託の種類については、一生懸命考える価値があると思います。ここには確実にぶら下がっている果物があるので、完璧を善の敵にせず、すべての侵入を検出できるアルゴリズムを考え出してみてください。

それはさておき、ぶら下がっている果物について話しましょう。ここで、分析の単位を個々のレコードからレコードのグループにシフトすると、生産性が高まると思います。

たとえば、すべてのレコードの半分がフィールドの一意の組み合わせを持っていると言いました。しかし、おそらく、たとえば、ほとんどのソースIPは複数のレコードに表示されます。これは、リクエスト内の他のフィールドが変更され、組み合わせが一意になるためです。リクエストをIPでグループ化すると、次のような質問をすることができます。

• 一部のIPが異常に多くのユーザー（または異常に少ない）として認証されているように見えますか？
• 一部のIPに異常に多くの認証エラーがありますか？
• 一部のIPには、異常なパターンのアクセスタイミングがありますか（たとえば、タイムゾーンで午前3時頃に大量のアクティビティが発生したり、1日1秒ごとに要求したりする）。

ユーザー名など、他のグループでも同様のことができます。

• このユーザーは、以前にすべての要求に同じコンピューターを使用したときに、別のコンピューターから認証を行っていますか？
• このユーザーは、以前に触れたことのないファイルシステムの一部に突然触れましたか？

ユーザーの潜在的な動作は非常に多様であり、時間の経過に伴う動作の変化に主に関心があるため、これに特に適していると思われる既製の分類子については知りません。つまり、各ユーザー/ IP /将来何をする可能性が高いかについて何らかのモデルを構築し、このモデルからの逸脱にフラグを立てたいということです。しかし、ユーザーが異なる行動パターンを持っている場合、それはかなり集中的なプロセスです！

この困難のため、今のところ、上で概説したような探索モード分析を行う方が生産性が高いと思います。これは、どのパターンのタイプが最も興味深いものであるかを通知する可能性が高く、その後、これらのパターンを検出するための空想的な統計アルゴリズムの使用を開始できます。

まず、攻撃のない期間のデータを記録するデータセットが必要だと思います。このデータセットは、正常に動作しているシステムに固有の変動をキャプチャする必要があります。これは注釈付きのデータセットを持つことではないということを強調したいと思います。

次に、メトリックのすべて（またはサブセット）を1つに結合しようとします。この新しいメトリックは、「驚き」の量を反映する必要があります。たとえば、低い値はシステムが正常に稼働していることを意味し、高い値のピーク/プラトーは急速な変化があることを意味します。ここでは、CUSUMまたはシューハートチャートスタイルのチャートについて考えています。

利用可能なデータの例をいくつか提供できますか？それは主に文字列、数字、1/0インジケータですか？

可能性は、攻撃なしでいくつかのバックグラウンドデータを与えられた機能間のベイジアンネットワークを学習することです。ベイジアンネットワークの学習は、機能間の条件付き独立性を引き出すので便利です。したがって、機能のありとあらゆる組み合わせを扱っているわけではありません。たとえば、フィーチャAがBとCに影響し、フィーチャBとCが一緒にDに影響する場合、AがBにどのように影響するか、BとCがDにどのように影響するかについてのモデルのみを学習します。このモデルで必要な数ははるかに少なくなります。確率分布全体よりもパラメータが多く、結合確率分布全体を格納するだけでなく、ベイジアンネットワークが使用される主な理由です。ベイジアンネットワークを指定して異常をテストするには、学習したベイジアンネットワークモデルを使用して、着信データポイントの確率を計算します。確率が非常に低い場合、

ベン・クーンからの反応は実用的で洞察に満ちていると思いました。

現在、私自身の経歴には、テキスト分類、エキスパートシステム、クラスタリング、およびセキュリティが含まれています。このような背景を考えると、会話に何か付け加えたいことがあるのではないかと思います。しかし、ベン・クーンによる以前の声明は、簡単なアプローチが多くの誤検知を引き起こす可能性があることを強調しています。多くの誤検知に直面したITスタッフは、常に誤検知を追跡する時間がないため、通常は「調整」します。

じゃあ何をすればいいの？

確かに、攻撃が含まれているログは役立つ可能性がありますが、企業が何らかの形で攻撃データを共有しない限り、問題22があります。一部のシリコンバレーの新興企業はこのような脅威の共有を追求しているかもしれませんが、他に何ができるでしょうか？

1つの可能なアプローチは、ネットワークのシミュレーションを作成してから、シミュレーションに対する攻撃を生成する方法を見つけることです。つまり、黒い帽子（シミュレートされたもの）が事前に白い帽子に知られていないシミュレーションを作成するとします。これらの攻撃を考慮して、これらの攻撃を発見するアルゴリズムを作成することができます。黒の帽子が白の帽子とは独立して動作する場合、私たちは展開する本当の戦いを持っています。攻撃者がシステムに侵入した場合、または検出されなかった場合、ホワイトハットはある程度失敗しています。

ブラックハットチームのセキュリティアナリストが成功した場合（違反行為や未発見の攻撃）、報奨金が支払われると、インセンティブ構造になる可能性もあります。同様に、白い帽子を構成するグループは、違反行為を止めたり、攻撃を検出したりすると報酬を受けます。

この配置には完璧なものは何もありません。明らかに、実際のブラックハットは、「フレンドリーな」ブラックハットチームの才能を超える可能性があります。それでも、かなりの量のデータ分析を行う人として、黒い帽子の理解を深めることなく、白い帽子の成功を定量化することは非常に難しいように思えます。結論はこれです。本当の黒い帽子が何をしているのかわからない場合、次善の策は友好的な黒い帽子です。

私もかなり変わった考えを持っています。フレンドリーな黒の帽子と白の帽子に加えて、灰色の帽子チームがいるとします。灰色の帽子とはどういう意味ですか？アイデアは簡単です。灰色の帽子は、フレンドリーな黒い帽子と白い帽子が何をしているかを見ることが許可されています。しかし、なぜ？

友好的なブラックハットがアプローチA、B、Cを使用して攻撃を開始し、ホワイトハットがこれら3つのアプローチのいずれも検出しないと仮定します。まあ、灰色の帽子は友好的な黒の帽子と白の帽子の両方がしていることを見る権限があり、彼らはこれらの未検出の攻撃を発見するためにどのような原理が使われるのかを考えようとします。グレーハットがそのような原則を見つけた場合、グレーハットチームは、正確な攻撃について詳細に説明せずに、これらの原則をホワイトハットチームと共有できます。

グレーハットチームが提供するこれらの「ヒント」が、ホワイトハットチームに多くを明らかにすることなく正しい方向への推進力を与えることを期待しています。

振り返ってみると、私の反応が本当に特定の技術に関するものではない場合はお詫び申し上げます。明らかに、私の反応は特定の技術についてではありません。しかし、私の経験では、機械学習の多くの問題（セキュリティの問題を含む）は、データが不十分であるために失敗することがよくあります。ホワイトハット、グレーハット、ブラックハットを使用するこのアプローチは、セキュリティ会社（またはITスタッフ）が防御の有効性を定量化できるだけでなく、ホワイトハットチームを推進する組織構造を提供できるデータの生成に役立つ可能性があります防御と監視を徐々に改善しました。

私が提案しているアプローチが独創的であるかどうか、私にはまったくわかりません。私は灰色の帽子について聞いたことがありませんが、実際には、灰色の帽子の役割は、あまり明らかにしないで、白いチームを前進させるために重要であると思います。

注：ここでの「灰色の帽子」という用語の使用は標準ではありません。http://www.howtogeek.com/157460/hacker-hat-c​​olors-explained-black-hats-white-hats-and-gray-hats/を参照してください。したがって、別の用語、おそらく「縞模様の帽子」を代わりに使用する必要があります。

しかし、それでもアイデアは変わりません。縞模様の帽子は、友好的な黒い帽子と防御側（白い帽子）の仕事を仲介するのに役立ち、特定のアイデアやヒントを白い帽子と慎重に共有できます。

元の質問を投稿したので、このトピックについて多くの調査を行い、結果を回答として提供できるようになりました。

まず、私たちの研究室では、異常検出アルゴリズムを利用したSIEMシステムを開発しています。システムとアルゴリズムの説明は私の論文にあります。大規模ネットワークにおけるセキュリティイベントの複雑な分析のためのシステムに向けて

それに加えて、Cross Validatedに関する同様の質問への私の回答で、そのようなデータを処理する方法に関する短い要約を書きました