1日でSIEM（情報セキュリティインシデント管理システム）を開発する方法

「同僚、この四半期に、情報セキュリティ管理のトピックに関するパートナー向けの高度なトレーニングコースが計画されています。 私たちのチームは、SIEMシステムの構築の問題に専念する実践的なレッスンを準備するように招待されています！」-そのような提案の後、チーフは別のボラティリティで一時停止しました。



演じられたとされる演者の中から、会議の参加者は、そのような提案が何を義務付けているのかを理解した（時間、労力、神経の出費に対する名声と名誉 ）。 しかし、SIEM（セキュリティ情報およびイベント管理）ソリューションの研究を実施することは私たちの活動分野の1つであるため、提供を拒否することはできませんでした。 息を吐き始めた。



2か月間のハードワークとレッスンの最終バージョンの準備の後、私たちはこの時間を非常に生産的に費やしたことを認めました。 そして彼らは、集団がそのような「挑戦」への答えをどれほど専門的に役に立つか想像さえしませんでした。



説得力のある例を使用して、1日で独自のSIEMシステムの開発に関するワークショップの資料を共有します。

免責事項 材料-膨大な量で、測定されたペースで授業の全学期に向けて設計されています。 例はプリミティブです。 著者は、SIEMオープンソースソリューションの産業応用の可能性を疑いますが、同時に、実例の研究が主題領域をよりよく理解するのに役立つと信じています。

ソースデータの分析と問題の説明

初期データを調整し、コースリスナーの平均「プロファイル」を決定します。 当社のパートナーは、情報セキュリティ（IS）の分野のエンジニアと専門家を派遣し、応用研究の実施、専門ソフトウェアの開発、関連サービスの提供を担当しています。



聴衆は、高等教育を受け、高度な学位と専門的資格を選択的に備え、準備され、経験されることを約束します。 コースの参加者は「番号を提供する」のではなく、新しい知識に興味があります。



教室では、理論の最小化と実践と利益の最小化を備えた最新のセキュリティインシデント管理システムの構築を検討することもパートナーの希望です。



そのため、次の期間中にワークショップを準備することを提案します。

• SIEMシステムを構築するためのよく知られたアプローチについて話します。
• 独自のソリューションを開発する例（プリミティブではあるが説得力がある）を使用して、同様のシステムのクラスのアーキテクチャ上の特徴を説明します。
• テストネットワークインフラストラクチャのセキュリティを監視するための「戦闘訓練」条件での独自のSIEMシステムの動作を実証します。

学生がネットワーク技術とプログラミングの基礎（PHPとC＃のコード例）に精通していることを願っています。



将来のレッスンのために材料の開発に進みます。

SIEMシステムの開発に関するワークショップ

はじめに、一般的な説明に限定します。



SIEMシステムの主なタスクは、さまざまなソースから保護されたインフラストラクチャに記録されたイベントを分析し、攻撃/攻撃シナリオ/疑わしいアクション/標準からの逸脱を検出し、必要に応じて適切なセキュリティインシデントを形成することです。



SIEMシステムの基本機能は、次のタスクに対するソリューションを提供する必要があります[1、2]：

• 着信セキュリティイベントの収集と保存。
• 記録されたセキュリティイベントの処理と分析。
• リアルタイムでのセキュリティポリシーの攻撃および違反の検出（リアルタイムに近い）;
• セキュリティインシデントの識別と分析。
• レポート生成。

さらに、次の機能の実装を保証するために、SIEMクラスの最新のソリューションに追加の要件が課されます[3]。

• 制御されたシステムのリソースのセキュリティの評価。
• IS管理システムが既存の要件と標準に準拠していることの検証。
• ISリスク管理など

SIEMシステムの機能モデルは、データ収集、前処理、保存、分析、プレゼンテーション[1]の機能サブシステムを組み合わせています。 SIEMソリューションでセキュリティイベントを処理する一般的なシーケンスを図[2]に示します。









さらに、実践的なスキルを開発するために独自のSIEMシステムを開発する例を検討することを提案します。



この例は、トレーニングWebアプリケーションの単純化された「ブルートフォース」攻撃シナリオをシミュレートします。 開発されたSIEMシステムのタスクは、そのような攻撃を実装する試みをセキュリティ管理者に通知することです。



テストベンチを構築するには、PHPとC＃のオープンソースソリューションと独自のアプリケーションを使用します。 テストベンチのアーキテクチャを次の図に示します（出版物のタイトル画像を繰り返します）。









ナビゲーションを簡単にするために、例のサブセクションには番号が付けられています。 練習する：

 1.テスト環境の構成。
      1.1。  Apache Webサーバーをインストールして構成します。
      1.2。  MongoDBデータウェアハウスをインストールして構成します。
      1.3。  RabbitMQメッセージブローカーをインストールして構成します。
      1.4。  Visual Studio開発環境をインストールして構成します。
 2.安全なWebアプリケーションBuggy Webappの開発。
 3. Apache Webサーバー用のコネクタの開発。
 4.相関カーネル（イベントハンドラー）の開発。
      4.1。  MongoDBデータウェアハウスパフォーマンス評価。
      4.2。 相関ルールのセットの形成。
      4.3。 相関のコアの実装。
 5.セキュリティ管理コンソールの開発。
 6. SIEMシステムによって開発された機能チェック。 

参照：

1. 「重要なインフラストラクチャ内の情報を保護するための情報およびセキュリティイベント管理技術の適用」は、SPIIRANコンピューターセキュリティ研究所の研究者チーム（I. V. Kotenko、I。B. Saenko、O。V. Polubelovaの最初の記事（2012）の1つです。 、A.A。Chechulin）、SIEMシステムの構築と運用に関する一般規定を備えています。 研究室の出版物の全リスト 。
2. 「セキュリティ情報とイベント管理（SIEM）実装」は、David Miller、Sean Harris et al。2011 Editionによる素晴らしい本で、いくつかの古い章がありますが、それでも大部分が関連しています。 SIEMシステムの体系的な体系的な外観、わかりやすい英語、わかりやすい例。
3. セキュリティ情報およびイベント管理のマジッククアドラント2015 。 2016年と2017年のGartnerテーマレポートは、SIEMシステムの研究者にも役立ちます。

1.テスト環境の構成

ご注意 使用されるソフトウェアソリューションの最新バージョンでスタンドが機能する可能性があります。 ただし、研究結果の再現性を確保するために、必要な依存関係がすべて明確になり、操作性がチェックされるバージョン番号を修正します。

1.1 Apache Webサーバーのインストールと構成

XAMPP for Windowsビルド 、バージョン7.1.9（Apache 2.4.27 + PHP 7.1.9）をWebサーバーとして使用します。 インストーラーを使用してXAMPPをダウンロードしてインストールし、デフォルトのインストールフォルダー-「c：\ xampp \」を選択します。



Webサーバーが正しくインストールされていることを確認するには、XAMPPコントロールパネルを開き、Apacheモジュールを実行します。 次に、ブラウザのアドレス「http://127.0.0.1/」で、XAMPPプロジェクトのウェルカムページが開きます。



エラーがない場合は、次の手順に進みます。

1.2 MongoDB Data Warehouseのインストールと構成

データウェアハウスを整理するには、MongoDBドキュメントデータベースを使用することをお勧めします 。 この選択の主な理由は、教育上の問題に対する解決策と、NoSQLアプローチに精通していることです。 さらに、市販のSIEMシステムの表面的な調査でさえ、従来のSQLデータベースとともに、ほとんどの主要メーカーがソリューションでNoSQL / NewSQLテクノロジーを使用していると結論付けることができます。



以下は、よく知られている1つの商用SIEMシステムのモデルであり、ソリューションのメーカー（以下で説明するメッセージブローカー）によるMongoDBおよびRabbitMQの使用を確認しています。









公式サイトからダウンロードし、インストールパッケージMongoDB Community Serverバージョン3.4.10をインストールします。 指示の例：

• MongoDBをサービスとしてインストールするための簡単な手順
• WindowsにMongoDB Community Editionをインストールする

コレクション（コレクション）テストのフィールド（フィールド）{a：1}で新しいドキュメント（ドキュメント）を作成することにより、サーバーのパフォーマンスをチェックします。 コレクション内のドキュメントを検索する試みは成功するはずです。









コレクションにドキュメントを追加するとき、MongoDBサーバーはデフォルトでObjectId型の _idフィールドでドキュメントを補完することに注意してください。 この「追加」は一意であり（ハッシュと混同しないでください、形成の規則は異なります）、コレクション内のドキュメントを一意に識別できます。



もう1つ、より視覚的なチェックを行いましょう。 Robomongoバージョン1.1.0-Betaなどの利用可能な管理ツールの1つをダウンロードし、MongoDBサーバーに接続します。 テストコレクションには、フィールド{a：1}で作成されたドキュメントが含まれている必要があります。









スクリーンショットでは、予想されるアドレス127.0.0.1の代わりに、アドレス192.168.137.1が示されています-実験では、複数の物理ワークステーションと仮想マシンで構成される分散テストベンチを使用します。 ただし、すべてのコンポーネントをホストオペレーティングシステムの同じワークステーションにインストールするのに問題はないはずです。



以下のデータウェアハウスのパフォーマンスを評価することが提案されています。



エラーがない場合は、次の手順に進みます。



有用なリンクと追加知識のソース：

• 人気の科学出版物NoSQL Distilled by Martin FowlerとPramod Sadalaj。 適切な翻訳があります- 「NoSQL：非リレーショナルデータベースの開発のための新しい方法論」。
• Habréの新鮮さから： 「SQLがNoSQLに勝る理由と、将来SQLがNoSQLにつながること」 、 「SQLまたは NoSQL- それが 問題です。 」

1.3 RabbitMQメッセージブローカーのインストールと設定

開発したシステムのコンポーネント間のデータ交換を整理するには、 stackshare.ioによるこのクラスの最も一般的なソリューションの1つであるRabbitMQメッセージブローカーを使用します 。



RabbitMQ Server for Windows（バージョン3.7.2）の推奨インストール手順に従います。 バージョンの依存関係を確認した後、 Erlangをインストールする必要があります-Erlangバージョン20.1はRabbitMQサーバー3.7.2に適しています。



インストーラーは、RabbitMQサーバーをサービスとして構成します。 さらに確認するために、「c：\ Program Files \ RabbitMQ Server \ rabbitmq_server-3.7.2 \ sbin \」ディレクトリに移動します。



サービス開始コマンドを実行します。

rabbitmq-service start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チームのステータスを確認する

 rabbitmqctl status
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステータスにエラーがない場合、すべてが正常です。



メッセージブローカーの機能を視覚的に監視するには、対応するプラグイン-管理プラグインを接続します。

 rabbitmq-plugins enable rabbitmq_management
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブラウザのアドレス「http://127.0.0.1:15672/」でプラグインを起動すると、管理パネルが使用可能になります（デフォルトのアカウントはゲスト/ゲストです）。









テストベンチを組み立てる際、アドレス192.168.137.1のノードにメッセージングサーバーをインストールしました。 管理パネルへのリモート接続が必要な場合は、新しいユーザーを作成して、適切な権限を付与する必要があります。次に例を示します。

 rabbitmqctl add_user siemuser siempass rabbitmqctl set_user_tags siemuser administrator rabbitmqctl set_permissions -p / siemuser ".*" ".*" ".*"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

管理パネルへの接続を確認した後、メッセージブローカーのインストールと設定が成功したと見なします。 次の手順でメッセージングの検証を実装します。



追加知識のソース：

• Redis Pub / Sub ：Redisは高速で安定した発行/購読メッセージングシステムです！ ご覧ください。
• Googleプロトコルバッファー

1.4 Visual Studio開発環境のインストールと構成

私たちのチームでセキュリティイベントを処理するためのカーネルの開発は、C＃で行われました。 したがって、例の一部はC＃にあり、個人的なものもホリバーもありません。 さらに、言語は理解するのに十分なほど単純であり、プロジェクトの教育目標と一致しています。



Visual Studio Community 2017を使用しています。インストールの開始点はwww.visualstudio.com/en/downloads/です。 最初のソリューションがC＃で構築されるまで、インストールの検証を延期します。

2.安全なWebアプリケーションBuggy Webappの開発

たとえば、ユーザー認証機能を実装する単純なWebアプリケーションを開発します。 マークアップのミニマリズムのアイデアに触発され、 Bootstrap 4を使用してアプリケーションをレイアウトします。 実装には、PHP言語を使用します。



バギーWebappアプリケーションのソースコード： buggy / admin.php



admin.phpスクリプトはユーザー名とパスワードを要求し、それらを管理アカウントの対応するパラメーター（admin / admin）と比較します。 ユーザー名とパスワードが一致しない場合、エラーメッセージが表示されます。









ユーザー名とパスワードが正しく入力されると、管理セクションへのアクセスが許可されます。









admin.phpファイルを適切なXAMPPビルドフォルダーに保存します（ファイルへのパスは「c：\ xampp \ htdocs \ buggy \ admin.php」です）。 XAMPPコントロールパネルからWebサーバーを起動します。その後、ブラウザーでアドレス「http://127.0.0.1/buggy/admin.php」からWebアプリケーションにアクセスできるようになります。 エラーがなければ、次に進みます。

3. Apache Webサーバー用のコネクタの開発

保護されたWebアプリケーションへの呼び出しを追跡し、疑わしいユーザーアクションを検出する方法 シンプルで理解しやすい方法は、Webサーバーのアクセスログ（アクセスログ）を表示することです。



使用される環境の場合、ヒットログはaccess.logファイルに保存されます（XAMPPの近似パスは「c：\ xampp \ apache \ logs \ access.log」です）。



ブラウザでWebアプリケーションを数回ダウンロードした後、ログファイルの内容を確認します。

 127.0.0.1 - - [01/Jan/2099:12:30:39 +0300] "GET /buggy/admin.php?username=hacker&password=123 HTTP/1.1" 200 2040 "http://127.0.0.1/buggy/admin.php" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

記録形式は、Apache Webサーバーのhttpd.conf構成ファイルで定義されています（XAMPPの近似パスは「c：\ xampp \ apache \ conf \ httpd.conf」です）。

 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined CustomLog "logs/access.log" combined
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フォーマットの詳細な説明を理解し、マッピングスキームを準備し、コネクタの開発に進みます。



コードの効率の問題は、プレゼンテーションの単純さの問題よりも、私たちの条件にとって重要ではないことを忘れないでください。



コネクタソースコード： ApacheConnector



アルゴリズムの一般的な説明：

1. 最初の段階では、アクセスログaccess.logに目を向け、ファイルサイズを記憶します。
2. 次に、反復間の休止を伴う無限ループで、ファイルサイズの変化を監視します。 サイズが大きくなると、ファイルから最後に追加された行を読み取り、それをRabbitMQメッセージキューに転送します。新しいファイルサイズを覚えておいてください。
3. access.logファイルは上書きされる場合があります。 このような場合（ファイルサイズの削減）を考慮します。

Jeffrey RichterとSteve McConnellの例に従って、コードの書式設定のスタイルを維持しようとします。 これらの本は両方とも関係者全員に強く推奨されています。



コネクタを構築するには、 .NET / C＃RabbitMQクライアントライブラリをプロジェクトに接続する必要があります 。 これを行う最も簡単な方法は、次のコマンドを使用して、Visual Studio開発環境のパッケージマネージャーコンソールに適切なNuGetパッケージをインストールすることです。

 Install-Package RabbitMQ.Client -Version 5.0.1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GitHub（ github.com/fisher85/AirSIEM ）で利用可能なソリューションを構築する場合、パッケージを手動でインストールする必要はありません-パッケージは自動的にダウンロードされます（インターネット接続のみが必要です）。



次のシナリオに従って、メッセージブローカーの正常性を確認しながら、コネクタのテスト実行を実行してみましょう。

1. ApacheConnectorアプリケーションを起動します。 コネクタは、access.logファイルのサイズの変更の追跡を開始します。
2. ブラウザーでは、Buggy Webapp Webアプリケーションページを数回更新しますが、ブラウザーに対応する行はWebサーバーにアクセスし、Webサーバーアクセスログに追加されます。
3. ApacheConnectorはファイルサイズの変更を検出し、最後の行をRabbitMQメッセージブローカーキューに送信します。
   
   
   
   
   
   
   
   
   
   
4. すべてが正しく構成されている場合、RabbitMQ管理パネル（この例のアドレスは「http://192.168.137.1:15672/」です）で、ゼロ以外の負荷の追加されたAirSIEM_ConnectorQueueキューが見つかります。
   
   
   
   
   
   
   
   
   
   

この方法でテストスクリプトが完了したら、次の手順に進みます。 それ以外の場合は、発生するすべてのエラーを排除する必要があります。



RabbitMQ設定のトラブルシューティングの適度な経験：

1. 最初に試すことは、ファイアウォール、ウイルス対策、プロキシなどを無効にすることです。それが役立つ場合は、それらを正しく有効にして設定します。
2. 相互作用するコンポーネント間でErlangハッシュ不一致エラーが発生した場合、ワークステーションにインストールされているErlangバージョンを1つだけ残してみてください。

コネクタ操作アルゴリズムに関する注意：

1. インスピレーションの源：Jeffrey Richter の本、 .NET 4.5 Programming （第27章、Asynchronous Computing Operations）およびLog Monitorプロジェクトの例 。
2. FileSystemWatcherを使用しないのはなぜですか？ 1つのケースでは、100万番目のクラスがファイルの変更を正しく追跡しません 。 このケースは、よく知られた法律に従って、実験中に観察されました。

4.相関カーネル（イベントハンドラー）の開発

そのため、この段階で、Apache Webサーバーという1つのソースからセキュリティイベントを収集するためのサブシステムを構成しました。 ApacheConnectorコネクタは、access.logヒットログの変更を監視し、最後の行をRabbitMQメッセージブローカーキューに送信します。

次の段階は、相関カーネル（イベントハンドラー）の開発です。 ただし、最初に、前述のように、MongoDBデータウェアハウスでの書き込みおよび読み取りの速度を評価することを提案します。 このコンポーネントが開発中のシステムのボトルネックになり、生産性の上限が決まると予想しています。

4.1 MongoDBデータウェアハウスのパフォーマンス評価

簡単な方法でパフォーマンステストを実行します。まず、リポジトリへの順次書き込み（単一のドキュメントとドキュメントパッケージ）の速度を推定し、次にコレクションからのドキュメントのランダム読み取りの速度を推定します。



アプリケーションのソースコード： MongoBenchmark / Program.cs



MongoDBを使用するには、MongoDB 用の.NETドライバーをプロジェクトに接続する必要があります。 これを行う最も簡単な方法は、次のコマンドを使用して、パッケージマネージャーコンソールに適切なNuGetパッケージをインストールすることです。

 Install-Package MongoDB.Driver -Version 2.5.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションを開始した後、ベンチマークの結果を評価します。

 InsertMany by 1: 20000 ops in 13.52 seconds (1479.15 ops/sec) => 1479.15 docs/sec InsertMany by 2: 10000 ops in 7.11 seconds (1406.24 ops/sec) => 2812.48 docs/sec InsertMany by 5: 4000 ops in 3.20 seconds (1250.93 ops/sec) => 6254.66 docs/sec InsertMany by 10: 2000 ops in 2.08 seconds (960.88 ops/sec) => 9608.78 docs/sec InsertMany by 50: 400 ops in 1.15 seconds (347.68 ops/sec) => 17384.15 docs/sec InsertMany by 100: 200 ops in 1.06 seconds (188.32 ops/sec) => 18832.26 docs/sec InsertMany by 250: 80 ops in 0.95 seconds (83.87 ops/sec) => 20968.05 docs/sec InsertMany by 500: 40 ops in 0.92 seconds (43.67 ops/sec) => 21835.64 docs/sec InsertMany by 1000: 20 ops in 0.93 seconds (21.39 ops/sec) => 21391.22 docs/sec InsertMany by 5000: 4 ops in 1.00 seconds (3.99 ops/sec) => 19936.32 docs/sec InsertMany by 10000: 2 ops in 1.01 seconds (1.97 ops/sec) => 19730.96 docs/sec InsertMany by 20000: 1 ops in 1.01 seconds (0.99 ops/sec) => 19832.80 docs/sec Find: 10000 ops in 6.17 seconds (1620.21 ops/sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

配布の「ハンプ」は、1つのパッケージ（ブロック）で500イベントを送信する場合に当てはまりますが、順次記録速度は1秒あたり21835ドキュメントです。 コレクションからのランダム読み取りの速度は、1秒あたり1620ドキュメントです。 テストベンチが「非トップ」構成のパソコンを使用して編成されているという事実を考慮すると、結果に非常に満足しています。 実験的に取得した書き込みおよび読み取り速度の値により、MongoDBデータウェアハウスは例で計画された負荷を処理できると考えています。



注：

• 運用時間の「測定」の問題に関する広く引用されたソース：Stack Overflow でのEnvironment.TickCountとDateTime.Nowの議論 。
• 同じ_idの2つのドキュメントをコレクションに挿入しようとすると、おおよその説明を含む例外MongoDB.Driver.MongoWriteExceptionとして迷惑になります。
  
  
  
  

   E11000 duplicate key error collection: test.events index: _id_ dup key: { : ObjectId('5a2a2b386a49df197845deaa') }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

4.2相関ルールのセットの形成

そしてもう一つの後退。 次のセキュリティイベントが発生すると、相関カーネルはプリロードされた処理ルール（個々のイベント間の依存関係を識別するルール、相関ルール）を適用しようとします。 ルールのテストセットを作成します。これは、後の例で使用します。



ルールを説明するために、OSSECプロジェクトで提案された相関ルール構文を最小限の変更で使用します。 この例では、保護されたWebアプリケーションの単純化された「ブルートフォース」攻撃シナリオをシミュレートしますこの例では、対応するtest_webapp_rules.xmlルールセットをコンパイルします 。

 <group name="web-app"> <rule id="100000" level="0"> <match>/buggy/</match> <description>Access to BUGGY webapp</description> </rule> <rule id="100001" level="0"> <if_sid>100000</if_sid> <match>password</match> <description>Attempt to login to BUGGY webapp</description> </rule> <rule id="100002" level="1" frequency="3" timeframe="5"> <if_matched_sid>100001</if_matched_sid> <same_source_ip/> <description>Brute force trying to login to BUGGY webapp</description> </rule> </group>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルールセットの形式は、XML形式とはわずかに異なります。 たとえば、ファイル内に複数のルート要素が存在することは許可されています。 このようなドキュメントは整形式の XMLドキュメントではありません; System.XML名前空間によって提供されるツールを使用してファイルを解析するとき、この機能を考慮します。



次に、各ルールを個別に検討し、構文の特徴を簡単に説明します。 最初のルール：

  <rule id="100000" level="0"> <match>/buggy/</match> <description>Access to BUGGY webapp</description> </rule>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

<rule>要素はルールを記述します。



<rule>要素のid属性は、ルールの識別子を定義します。 「著作権」ルールのOSSECプロジェクトが推奨する範囲から識別子を選択します：> = 100000。



<rule>要素のlevel属性は、ルールの重要度のレベルを定義します。 最小値は0（通常、セキュリティ管理コンソールには表示されません）、最大値は16です。



<match>要素は、処理されたメッセージの文字列で検索するサブストリングを設定します。



<description>要素は、セキュリティ管理者へのアラートとして表示されるルールの説明を定義します。



このルールのトリガーのケースは単純にチェックされます-<match>要素で指定されたサブストリングが処理中のメッセージの行で見つかった場合、相関コアはセキュリティアラートを生成します。



ルール100000のロジックは次のとおりです。保護されたBuggy Webapp Webアプリケーションへのすべてのアクセス試行をセキュリティシステムに通知します。 これを行うために、Webサーバーへのすべての呼び出しで部分文字列「/ buggy /」が追跡されます。 100000ルールの重要度レベルはゼロです。監視対象の呼び出しに重要性はありません。ルールトリガーを使用して、より複雑なルールチェーンを構築します。



実際、100,000ルールはセキュリティイベント間の依存関係を検出せず、「相関」を明らかにしないことに注意してください。 この意味で、このようなレコードを相関ルールではなく処理ルールと呼ぶ方が正しいです。



2番目のルール：

  <rule id="100001" level="0"> <if_sid>100000</if_sid> <match>password</match> <description>Attempt to login to BUGGY webapp</description> </rule>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール100001の説明には、ルール100000の識別子を持つ新しい要素<if_sid>があり、これは追加のトリガー条件を課します-これより前にルール100000が機能する必要があります。



ルール100001のロジック：処理中の行が保護されたWebアプリケーションへのアクセスに関連する場合（ルール100000は以前に機能していました）、同時にWebサーバーへの呼び出しでサブストリング「パスワード」が見つかりました（パスワードのユーザー名およびパスワード入力フォームへの転送を示す可能性があります） 、セキュリティシステムに管理アクセスを取得する試みを通知します-「BUGGY webappへのログイン試行」。



ルール100001では、個々のセキュリティイベント間の依存関係を識別でき、相関ルールと正しく呼ぶことができます。



3番目のルール：

  <rule id="100002" level="1" frequency="3" timeframe="5"> <if_matched_sid>100001</if_matched_sid> <same_source_ip/> <description>Brute force trying to login to BUGGY webapp</description> </rule>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール100002の説明には、ルール100001の識別子を持つ新しい要素<if_matched_sid>があり、追加のトリガー条件を課します-ルール100001が最後の5秒（時間枠内で<rule>要素の属性頻度= "3"）少なくとも3回動作する必要があります= "5"）。



空の<same_source_ip />要素は、<if_matched_sid>要素で指定されたルールの応答をカウントするときに、一致するソースIPアドレスを持つイベントのみが考慮されることを示します。



ルール100002のロジック：保護されたWebアプリケーションへのアクセスを取得するために同じアドレスから最後の5秒間に多くの試行（3回以上）が行われた場合、アクセスパスワードを選択する試みについて、より高い重要度レベル= 1のアラートを生成します-「BUGGY webappにログインしようとするブルートフォース」。



検討中の例の相関ルールのセットが形成されており、イベントハンドラーの即時実装に進みます。 例の最後で、相関コアの段階的なデバッグを実行し、相関ルールが着信セキュリティイベントにどのように適用されるか、どのアラートが生成されるかを確認します。

4.3相関コアの実装

相関コアのソフトウェア実装は、この例の最も複雑で膨大な部分であり、開発されたSIEMシステムのセキュリティイベントを処理するロジック全体を本質的に定義します。



一般的に、相関コアのロジックは次のとおりです。

1. 相関コアは、AirSIEM_ConnectorQueueメッセージキューをリッスンします。
2. 次のメッセージ（イベント）が到着すると、カーネルはプリロードされたイベント処理ルール（相関ルール）をそれに適用しようとします。
3. ルールの1つが受信したセキュリティイベントに適用される場合、カーネルは必要に応じてセキュリティインシデントを生成し、MongoDBデータウェアハウスのアラートコレクションに保存します。

ソースコード： AirSIEM



実装は非常に膨大になるため、デバッグの便宜上、 NLogロギングシステムをプロジェクトに接続します。 これを行う最も簡単な方法は、次のコマンドを使用して、パッケージマネージャーコンソールに適切なNuGetパッケージをインストールすることです。

 Install-Package NLog -Version 4.4.12
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、メッセージブローカーと連携するには、RabbitMQ.Clientパッケージを接続し、データウェアハウスであるMongoDB.Driverパッケージとやり取りする必要があります。

 Install-Package RabbitMQ.Client -Version 5.0.1 Install-Package MongoDB.Driver -Version 2.5.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NLogロガーの構成手順に従って 、nlog.config構成ファイル（ サンプルコンテンツ ）をプロジェクトに追加し（[プロジェクト]メニュー> [既存項目の追加]）、それを出力ディレクトリにコピーする必要があることを示します（ソリューションエクスプローラーウィンドウに移動> nlog.configファイルを選択>に移動） [プロパティ]ウィンドウで、[出力ディレクトリにコピー]プロパティで[常にコピー]を選択します。



プロジェクトのソースコードを読み込み、ソリューションを収集します。 開始する前に、構成ファイルAirSIEM.exe.configの設定を確認します。これは、ルールへのパスと、メッセージブローカーとデータストアへの接続文字列が正しく指定されていることです。



相関カーネルの正しい動作を検証するには、攻撃スクリプト（関連ルールで指定）が検出された場合、カーネルがセキュリティインシデントを生成し、MongoDBデータウェアハウスのアラートコレクションに保存することを確認する必要があります。 すべてのシステムコンポーネントの開発後、最終段階で検証を実行することを提案します。

5.セキュリティ管理コンソールの開発

セキュリティ管理者の便宜のために、適切なソリューションである管理コンソールを提供します。 コンソールの機能は、生成されたセキュリティインシデントの表示に限定され、実装オプションはPHP Webアプリケーションです。



ソースコード： console / index.php



PHPコードがMongoDBと対話するには、2つのアクションを実行する必要があります。適切な拡張機能をPHPインタープリターに接続し、対応するライブラリをWebアプリケーションに接続します。

5.1 php_mongodb.dll拡張機能をWebサーバーに接続する

XAMPP for WindowsアセンブリをWebサーバーとして使用することを思い出してください。 デフォルトでは、PHPインタープリターはMongoDBストレージの存在を認識しません; WindowsドライバーにMongoDB PHPドライバーをインストールすることでこれを修正できます。



ケースのインストール手順を開きます-WindowsでのMongoDB PHPドライバーのインストール 。



適切なバージョンのphp_mongodb.dllドライバーを探してサイトpecl.php.net/package/mongodbにアクセスします。 最新の安定バージョン（1.4.0）、Windows OS、PHPバージョン7.1、スレッドセーフ、x86を選択します。 選択したアーカイブはphp_mongodb-1.4.0-7.1-ts-vc14-x86.zipで、目的のファイルphp_mongodb.dllはアーカイブにあります。



php_mongodb.dllドライバーをPHP拡張フォルダーにコピーします。 デフォルトは「c：\ xampp \ php \ ext \」です。 「extension = php_mongodb.dll」という行を、拡張機能をPHP設定ファイルに接続するためのセクションに追加します（デフォルトでは、「c：\ xampp \ php \ php.ini」）



Apacheを再起動します（最も簡単な方法はXAMPPパネルから）。その後の手順で、「Uncaught Error：Class 'MongoDB \ Driver \ Manager' not found」などのエラーの解析に時間をかけすぎないようにします。

5.2 MongoDB PHPライブラリWebアプリケーションへの接続

次に、MongoDB PHPライブラリを管理者コンソールプロジェクトに接続する必要があります。



私たちは公式文書を研究しています 。 このガイドでは、 Composerを使用する最も簡単な方法を推奨しています。



Composerをインストールして、使用例に慣れてください。



将来のプロジェクト用のフォルダー（たとえば、「c：\ xampp \ htdocs \ console \」）を作成し、フォルダー内のmongodbパッケージのインストールコマンドを実行します。

 composer require mongodb/mongodb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コマンドの結果：









Composerは必要なファイルをダウンロードし、プロジェクトに追加します。プロジェクトでMongoDB PHPライブラリの機能を使用するには、コードに1行追加する必要があります。

 require_once __DIR__ . "/vendor/autoload.php";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションコードをファイル「c：\ xampp \ htdocs \ console \ index.php」に保存し、ブラウザで開きます。









テスト実行中の相関カーネルがセキュリティインシデントを生成し、MongoDBデータウェアハウスのアラートコレクションに対応するドキュメントを保存した場合、最初の実行時にテーブルが空にならない場合があります。



エラーがなければ、最終段階に進みます。



追加知識のソース：

1. MongoDB PHPドライバー
2. MongoDB PHPライブラリ
3. MongoDB PHPライブラリをインストールする

6. SIEMシステムによって開発された機能チェック

これで、SIEMシステムの開発が完了しました。最終段階では、相関カーネルの段階的なデバッグを実行し、ソリューション全体が正しく機能することを確認する必要があります。



開発中のシステムの主なタスクを思い出してください-保護されたWebアプリケーションに関連して「ブルートフォース」攻撃シナリオを実装する試みをセキュリティ管理者に通知します。



一般的な最終テストシナリオを検討します。

1. 攻撃者は、保護されたBuggy Webapp Webアプリケーションのadmin.phpページを開き、管理者のユーザー名とパスワードを見つけようとします。
2. – «admin/admin» – ( – ).
3. SIEM , .

さらに、テストシナリオを実行し、SIEMシステムの一連のアクションを考慮することが提案されています。



ステップ1.準備。

実験の「純度」については、データウェアハウスをクリアします。これを行うには、Robomongoを使用してMongoDBに接続し、AirSIEMデータベースを削除します（存在する場合）。



ApacheConnectorを起動します。



ステップ2.攻撃者のアクションのモデリング。

ブラウザのアドレス「http://127.0.0.1/buggy/admin.php」でBuggy Webapp Webアプリケーションを開きます。 5秒以内に、管理者のユーザー名とパスワードの選択を3回試みます。



手順3.コネクタを確認します。

ApacheConnectorアプリケーションウィンドウで、Webサーバーのアクセスログを読み取り、登録されたセキュリティイベントをメッセージブローカーキューに転送することを確認します。



RabbitMQメッセージブローカーの管理パネル（「http://127.0.0.1:15672/」）で、load：メッセージの存在をAirSIEM_ConnectorQueueキューに表示する必要があります。



ステップ4.相関カーネルの動作を確認します。

次に、相関コアは処理プロセスに入ります。AirSIEMアプリケーションを起動します。NLogロガーのLogs / log.txtログファイル（アセンブリ出力ディレクトリへの相対パス）によって正しい操作を評価します。



準備段階では、相関ルールがロードされます。

 ----- AirSIEM start ----- ParseRuleDir start ParseRulesFromXML handles file: test_webapp_rules.xml 3 rules processed: 100000, 100001, 100002 ParseRuleDir: total 1 files processed ParseRuleDir: total 3 rules processed ParseRuleDir stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルールをロードすると、ルールチェーンが構築されます。

 CheckDependencies start Dependencies: 100000 children => 100001 100001 children => 100002 100002 children => CheckDependencies stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、キューが作成され、<if_matched_sid>要素で識別子が見つかったルールがトリガーされた回数をカウントします。テストセットには3つのルールが含まれ、そのうち1つのルール100002のみが別のルールのトリガーをカウントします-識別子100001。識別子100001のキューが作成されます。

 GenerateQueueList start Created 1 queues: [100001, FireQueue object => ID=[100001], count=[0], timeFrame=[5 sec], maxSize=[1000]] GenerateQueueList stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、「サブスクライバ」が初期化されて起動され、AirSIEM_ConnectorQueueキューを「リッスン」し、受信したメッセージをハンドラーに渡します。

 RabbitMQConsumer init RabbitMQConsumer start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

攻撃者がユーザー名とパスワードを取得しようとする最初の試みの後、ApacheConnectorコネクターはWebサーバーのアクセスログログから次の行をRabbitMQキューに渡し、「サブスクライバー」はメッセージを受信して​​処理のために送信します。

 RMQ message received: ApacheConnector:127.0.0.1 - - [01/Jan/2099:16:24:57 +0300] "GET /buggy/admin.php?username=1&password...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メッセージから正規化されたセキュリティイベント（SecurityEventクラスのインスタンス）が生成されます。

 SecurityEvent object => timestamp=[16:24:57], source=[127.0.0.1], destination=[], message=[GET /buggy/admin.php?username=1&password=1 HTTP/1.1]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、相関カーネルはロードされたルールを処理中のイベントに適用します。最初の「パス」では、トリガーが他のルールに依存しないルールのみが表示されます。

 Check rule 100000 - Access to BUGGY webapp Check <match>/buggy/</match> Rule 100000 matched ALERT: LEVEL 0 - Access to BUGGY webapp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール100000がトリガーされ、セキュリティインシデントが生成され、通知がMongoDBに送信され、管理者コンソールに表示されます（デバッグ中、クリティカルレベルがゼロであってもすべてのアラートが表示されます）。



次に、ルールは再帰的にスキャンされ、そのトリガーはルール100000のトリガーに依存します。

  Check the child rules Check rule 100001 - Attempt to login to BUGGY webapp Check <if_sid>100000</if_sid> Check <match>password</match> Rule 100001 matched ALERT: LEVEL 0 - Attempt to login to BUGGY webapp Matched rule is queue tracked Enqueue item: FireQueueItem object => timestamp=[16:24:57], source=[127.0.0.1], destination=[] FireQueue object => ID=[100001], count=[1], timeFrame=[5 sec], maxSize=[1000] 1: FireQueueItem object => timestamp=[16:24:57], source=[127.0.0.1], destination=[] Check the child rules Check rule 100002 - Brute force trying to login to BUGGY webapp Check <if_matched_sid>100001</if_matched_sid> QueueDictionary.CheckIfMatched start counter++ => counter=[1] counterSameSourceIP++ => counterSameSourceIP=[1] Rule 100001 QueueDictionary.CheckIfMatched == FALSE Rule 100002 not matched Check rule 100002: OK Check the child rules: OK Check rule 100001: OK Check the child rules: OK Check rule 100000: OK
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

処理の結果として、ルール100001がトリガーされ、最初の操作がFireQueueカウントキューに入力されます。応答の数が3に等しくなると、ルール100002のアクティブ化の条件の1つが満たされます



。Webアプリケーションへの2番目の呼び出しの処理をスキップし、すぐに3番目のパスワード選択の試行に進みます。

 RMQ message received: ApacheConnector:127.0.0.1 - - [01/Jan/2099:16:25:02 +0300] "GET /buggy/admin.php?username=1&password... SecurityEvent object => timestamp=[16:25:02], source=[127.0.0.1], destination=[], message=[GET /buggy/admin.php?username=1&password=1 HTTP/1.1] Check rule 100000 - Access to BUGGY webapp Check <match>/buggy/</match> Rule 100000 matched ALERT: LEVEL 0 - Access to BUGGY webapp Check the child rules Check rule 100001 - Attempt to login to BUGGY webapp Check <if_sid>100000</if_sid> Check <match>password</match> Rule 100001 matched ALERT: LEVEL 0 - Attempt to login to BUGGY webapp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール100001がトリガーされた後、FireQueueカウントキュー内の回数がカウントされているかどうかがチェックされますか？実際、ルールID 100001には、次のようなキューが存在します。

  Matched rule is queue tracked Enqueue item: FireQueueItem object => timestamp=[16:25:02], source=[127.0.0.1], destination=[] FireQueue object => ID=[100001], count=[3], timeFrame=[5 sec], maxSize=[1000] 1: FireQueueItem object => timestamp=[16:24:57], source=[127.0.0.1], destination=[] 2: FireQueueItem object => timestamp=[16:25:01], source=[127.0.0.1], destination=[] 3: FireQueueItem object => timestamp=[16:25:02], source=[127.0.0.1], destination=[]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カウントキューでは、時間枠間隔（5秒）でのルール100001の3つの応答が固定されています。セキュリティイベントの処理は続行されます。

  Check the child rules Check rule 100002 - Brute force trying to login to BUGGY webapp Check <if_matched_sid>100001</if_matched_sid>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この時点で、ルールが100001で機能する回数がチェックされます<same_source_ip />要素がルールの説明に存在するため、ソースIPアドレスの同じ値を持つ操作がカウントされました。

  QueueDictionary.CheckIfMatched start counter++ => counter=[1] counterSameSourceIP++ => counterSameSourceIP=[1] counter++ => counter=[2] counterSameSourceIP++ => counterSameSourceIP=[2] counter++ => counter=[3] counterSameSourceIP++ => counterSameSourceIP=[3] Rule 100001 QueueDictionary.CheckIfMatched == TRUE Rule 100002 matched ALERT: LEVEL 1 - Brute force trying to login to BUGGY webapp Check rule 100002: OK Check the child rules: OK Check rule 100001: OK Check the child rules: OK Check rule 100000: OK
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール100002がトリガーされ、相関コアが「パスワードブルートフォース」攻撃シナリオを検出し、対応するセキュリティインシデントを生成します。インシデント情報はMongoDBデータウェアハウスに送信されます。



手順5.データウェアハウスを確認します。

アラートの形成を確認してください。これを行うには、Robomongoを使用してMongoDBに接続し、AirSIEMデータベースのアラートドキュメントのコレクションを調べます。コレクションは空でない必要があります。



ステップ6.セキュリティー管理者のアクションのモデリング。

ブラウザのアドレス「http://127.0.0.1/console/index.php」でセキュリティ管理者のコンソールを開きます。 SIEMシステムのすべてのコンポーネントが正しく構成されている場合、テストスクリプトの実行後、コンソールウィンドウは次のようになります。









個々のイベントが検出されただけでなく、攻撃者の一連のアクションが特定され、攻撃シナリオが特定されたことを強調します。管理者のコンソールでは、これは行番号7で、色で強調表示され、「ブルートフォース」攻撃シナリオの検出された実装に関するメッセージが表示されます。タイムスタンプ16:25:03は相関コアによって設定されます;値は、攻撃者へのアクセスを取得する3回目の試行（16:25:02）に対応するイベントのタイムスタンプとは異なります。



重要度がゼロのアラートが誤検知と見なされる場合、コンソールへの出力を無効にできます。これにより、オペレーターの負荷が軽減されます。



まとめ



セキュリティ管理者は、攻撃者によって疑わしいアクティビティが通知されます。SIEMが開発したシステムがタスクを完了しました。カーテン。

結論と結論

このレッスンの資料では、独自のSIEMソリューションを開発する例により、最新のセキュリティインシデント管理システム（SIEM）の構築の問題に対処しました。保護されたWebアプリケーションのセキュリティモニタリングにおける開発システムの実用化の可能性が実証されています。「パスワードブルートフォース」タイプの攻撃者の攻撃シナリオが正常に検出され、インシデントが生成され、管理者に通知されました。



上記の例は非常に原始的であり、情報セキュリティツールのクラスとしてのSIEMシステムのアーキテクチャおよび機能の多くを反映していないことに同意する必要があります。注意深い読者は、最終的なソリューションがSIEMよりもWAFに似ていることに気付くでしょう。



さらに、著者は、オープンソースのSIEMソリューションの産業応用の可能性を疑い、ほとんどの立場で、アントン・チュバキンの意見に同意します- 「なぜオープンソースのSIEMがないのですか？」。



同時に、著者は、シンプルでわかりやすい例（コード例を含む）を使用してSIEMシステムに精通することで、研究者が主題領域を詳細に理解し、おそらく新しい発見を促すことができると確信しています。そして、情報セキュリティインシデント管理の専門家を増やしましょう！



使用済みプロジェクトのすべてのソースコードは、GitHubのオープンなAirSIEMリポジトリにあります。



著者はすべてのコメント、コメント、提案に喜んで協力します。ご清聴ありがとうございました。レッスンの主要部分は完了し、質問に答える準備ができました。