その間に、SEC（Simple Event Correlator）を使用してOSSIM / USMの情報セキュリティイベントの相関の機能を拡張するというアイデアが思い浮かびました。
ソリューションのアーキテクチャを次の図に示します。
ソリューションの簡単な説明
OSSIMサーバーまたはスタンドアロンサーバーにデプロイされたSECは、OSSIM PLUGIN（FILE 5）によって処理されたテキストファイルからログのコピーを受け取ります。 分析に基づいて、SECはファイルに書き込まれるイベントとアラートを生成します（FILE 6）。 このファイルは、OSSIM用に特別に開発されたPLUGINによって読み取られます。 したがって、SECによって生成されたイベントは、OSSIMコンソールで確認したり、それらに優先順位を付けたり、アラートを実行したりできます。
もちろん、このソリューションでは、SECアラートを生成したイベントのドリルダウン検索は困難です。 この欠点を補うために、それらを生成した元のイベント（アラート）のSECコピーによって生成されたアラートに含めることができます。
次に、小さな例を分析します。
この例は非常に原始的であり、機能を示すためだけに作成されました。 さらなる開発では、SEC相関ルールが機能する基準に基づいて、OSSIMシステムのuserdataXフィールドに「生のイベント」を配置する機能。 したがって、SECによって生成されたインシデントを表すイベントをOSSIMインターフェイスで開くことにより、それを引き起こした初期イベントをすぐに見ることができます。
例
例を見てみましょう。 suricata署名変更イベントを登録するとします。
このアラートのトリガーは、次の2つのイベントです。
- /etc/suricata/suricata.ymlファイルへの変更を示すauditdデーモンイベント。
- suricataサービスの開始に関するsuricataログからのイベント。
suricata.yml設定ファイルへの変更を記録するために必要に応じてauditdがすでに設定されていると仮定します。 次に、この問題を解決するには以下が必要です。
- /var/log/sec_input.logなど、SECを読み取るファイルへのauditdおよびsuricataログのリダイレクトを構成します。
- 上記の条件が満たされたときにアラートを生成するSECルールを構成します。
- SECがアラートログ、/ var / log / sec_output.logを書き込むファイルを読み取るOSSIMプラグインを作成します。
リダイレクト設定
ここではすべてが非常に簡単です。 問題を解決するには、次の構成を使用します
syslog-ng (/etc/syslog-ng/syslog-ng.conf): source s_audit_file { file("/var/log/audit/audit.log"); }; source s_suricata_file { file("/var/log/suricata.log"); }; destination d_sec { file("/var/log/sec_input.log"); }; log { source(s_ audit_file); source(s_suricata_file); destination(d_sec); };
したがって、監査ログとmeerkatログ（停止と開始のみ）は/var/log/sec_input.logファイルに送信されます。 このファイルはSECを読み取ります。
SECセットアップ
メインSEC構成ファイルの内容（/ etc / default / sec）：
RUN_DAEMON="yes" DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/sec_input.log -pid=/var/run/sec.pid -detach -log=/var/log/sec_output.log"
SECを読み取るファイル（入力パラメーター）、相関ルールを含むファイル（confパラメーター）、およびSECが操作のログと単なる情報メッセージ（logパラメーター）を書き込むファイルを定義します。
SEC規則ファイル（/etc/sec.conf）は次のとおりです。
type=PairWithWindow ptype=RegExp pattern=syscall=5\s+success=yes.*key="suricata-file" desc=Suricata config modified action=logonly ptype2=RegExp pattern2=threads initialized, engine started desc2=src_ip=NULL dst_ip=NULL user=NULL msg="Suricata restart initiated with new config file" action2=logonly window=600
次の図に示すように、ソースからの2つのイベントを相関させる1つのルールのみが含まれます。
OSSIMプラグイン
OSSECプラグインは、SECによって生成されたイベントを処理するために作成されます。 処理の便宜上、イベント（イベント）には1つの形式が必要です。
このプラグインは、たとえばここで説明するように、テキストファイルを読み取るための通常のプラグインとして開発されています。 プラグインの開発に関与していない場合は、以下で説明するすべての内容が理解できるように、参照して記事を流referenceに読むことをお勧めします。
この例のプラグインの説明にSECイベント形式を使用しました。 フィールドを追加したり、フィールドを追加または削除できます。
なぜ単一のフォーマットが必要なのですか？ 結局のところ、SECイベントの新しいタイプごとにregexpをプラグイン構成ファイルに追加することは可能ですか？
はい、できます。 しかし、私は統一の支持者です。 単一の形式がある場合、新しいタイプのSECイベントを追加するために必要なのは、対応するsqlファイルに1行の説明を追加することだけです。 新しいタイプのイベントの追加は、非常に簡単なプロセスです。
したがって、形式は次のとおりです（もちろん、syslogヘッダーなし）。
event_name = <イベント名> src_ip = <アドレス> dst_ip = <アドレス> user = <ユーザー名> msg = <実際の情報メッセージ>
SECメッセージの例：
Sun Sep 3 23:26:06 ossim_server: src_ip=NULL dst_ip=NULL user=NULL msg="Suricata restart initiated with new config file"
sec.confプラグイン構成ファイルは次のとおりです。
[DEFAULT] plugin_id=9006 [config] type=detector enable=yes source=log location=/var/log/sec_output.log create_file=false process= start=no stop=no restart=no startup= shutdown= [translation] suricata_conf_change=1 [0001 - Suricata Modified Config] event_type=event regexp="(?P<DATE>\w+\s+\w+\s+\d+\s+\d+\:\d+\:\d+)\s+(?P<HOST>\S+)\:\s+event_name=(?P<EVENT_NAME>\S+)\s+src_ip=(?P<SRC_IP>\S+)\s+dst_ip=(?P<DST_IP>\S+)\s+user=(?P<USER>\S+)\s+msg=(?P<MSG>.*)" plugin_sid={translate($EVENT_NAME)} device={$HOST} username={$USER} src_ip={$SRC_IP} dst_ip={$DST_IP} userdata1={$MSG}
Sec.sql構成ファイル：
DELETE FROM plugin WHERE id = "9006"; DELETE FROM plugin_sid where plugin_id = "9006"; INSERT IGNORE INTO plugin (id, type, name, description) VALUES (9006, 1, 'sec', 'Simple Event Correlator'); INSERT IGNORE INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (9006, 1, NULL, NULL, 'SEC: Suricata Config Changed');
.sqlファイルをインポートします。
ossim-db < /usr/share/doc/ossim-mysql/contrib/plugins/sec.sql
プラグインをオンにします。
そして結果を楽しんでください：
その他の詳細：
