• はじめに
• DSMエディターの概要
  • DSMエディターの開始と使用
  • サンプル・ログについて
• 演習1：カスタムDSMの作成
  • 1-1：ログソース・タイプの作成
  • 1-2：標準プロパティーとカスタム・プロパティーの切り出し
  • 1-3：イベント・マッピングの作成
• 演習2：カスタムDSMのテスト[検索編]
  • 2-1：ログソースの定義
  • 2-2：サンプル・ログの再生
  • 2-3：ログの検索とグラフ化
  • 2-4：AQLによる拡張検索の使用
  • 2-5：AQLによる拡張検索とリファレンス・セット
• 演習3：カスタムDSMのテスト[相関分析編]
  • 3-1：生成されたオフェンスの確認
  • 3-2：標準ルールの内容

はじめに

QRadar CE(Community Edition)は、もうお試しいただけましたでしょうか。

DSMを追加することで対応するログを増やしていけますので、様々なログを取り込んで分析できます。Windowsなど一般的なログであれば、手順に沿って構成するだけで正規化されたログを利用できます。
サポートされているDSMも幅広いのですが、カスタム・アプリケーションのログなど、標準では対応していないログ形式も存在します。

任意形式のログを処理できるようにするために、QRadarには DSMエディター という機能があります。
DSMエディターを使用することで、QRadar がイベント・データをパーシングする方法をカスタマイズできます。

DSMエディターを使用する場面は、大きく分けて 2つあります。

• 1つ目は、標準でサポートされているイベント・ソースに対してパーシングを上書きしたりプロパティーを追加するケース
• 2つ目は、カスタム・ログソースのパーシングを定義するケース

です。今回は、2つ目のカスタム・ログソースのパーシングについて説明します。

カスタム・ログソースのためのDSMは、Universal DSM や uDSM と呼ばれることもあります。ただ、標準でサポートされているDSMの中にも、内部的に Universal DSM を使用しているものがありますので、厳密にはイコールではありません。ここで取り扱う範囲では、ほぼ同じように考えても問題はないでしょう。

DSMに関連して登場する概念に、「プロトコル」があります。
一般的な技術用語にもプロトコルは存在しますが、QRadar における「プロトコル」は、モジュールとしてインストールしたり構成を行う対象です。
DSMは、プロトコルが処理した後のペイロードに対してパーシングや正規化を行います。
DSMとプロトコルの組み合わせにはサポート上の制限があり、全てを自由に入れ替えることはできません。しかし、多くのDSMは複数のプロトコルに対応しています。
特にカスタムDSMを作成するためのベース機能である Universal DSM は、多くのプロトコルに対応しています。

トップに戻る

DSMエディターの概要

DSMエディターは、統一されたフロントエンドとして、複数の異なる內部コンポーネントの作成/構成、ならびにテスト/シミュレーション(プレビュー機能)を行います。

DSMエディターでは、次の構成が可能です。

• ログソース拡張
  • QRadar の標準化/正規化フィールドに対する構文解析の動作を制御するために使用します。
  • ログソース拡張に含まれるプロパティー：
    • EventName (イベントID) ★
    • EventCategory (イベント・カテゴリー) ★
    • SourceIp (送信元IP)、SourcePort (送信元ポート)
    • DestinationIp (宛先IP)、DestinationPort (宛先ポート)
    • SourceIpPreNAT (NAT前の送信元IP)、SourceIpPostNAT (NAT後の送信元IP)、SourcePortPreNAT (NAT前の送信元ポート)、SourcePortPostNAT (NAT後の送信元ポート)
    • DestinationIpPreNAT (NAT前の宛先IP)、DestinationIpPostNAT (NAT後の宛先IP)、DestinationPortPreNAT (NAT前の宛先ポート)、DestinationPortPostNAT (NAT後の宛先ポート)
    • SourceMAC (送信元MAC)
    • DestinationMAC (宛先MAC)
    • SourceIpv6 (IPv6送信元)
    • DestinationIpv6 (IPv6宛先)
    • DeviceTime (ログ・ソースの時刻)
    • Protocol (プロトコル)
    • UserName (ユーザー名)
    • HostName (アイデンティティー・ホスト名)
    • GroupName (アイデンティティー・グループ名)
    • NetBIOSName (アイデンティティーNetBIOS名)
    • ExtraIdentityData (アイデンティティー拡張フィールド)
  • ★イベント ID およびイベント・カテゴリーの定義は必須です。

• カスタム・プロパティー

  • ログソース拡張には含まれない、任意の外部プロパティーを定義するために使用します。(URL、ハッシュ値など)

• QID マップ・ エントリー

  • QIDは、QRadar のイベント・タイプのディクショナリーを構成する、イベント名/イベント説明/下位カテゴリーのレコードです。
  • QRadarは、正規化されたイベントの名前と説明、重大度、下位カテゴリー、グローバル固有のQID 値を持っています。
  • 下位カテゴリー(LLC)は、上位カテゴリー(HLC)に紐付いています。
    • 上位カテゴリー(HLC)の例：認証、アクセス、エクスプロイト、マルウェア、ポリシー…など
    • 下位カテゴリー(LLC)の例：(HLCが「認証」の場合) SSHセッション開始、RADIUS認証失敗、FTPログアウト、管理者セッション開始…など
    • QRadarに定義されているカテゴリーについては、「イベント・カテゴリー」を参照してください。
  • ヒント：カテゴリーのおかげで、複数ベンダーのFirewallやOSなどが混在していても、例えば「認証失敗」はどのログでも「認証失敗」という意味でまとめて扱うことができます。

• イベント・マッピング

  • DSM やログ・ソース拡張により作成される「イベント・キー」 (イベント ID とイベント・カテゴリー) を QID レコードに関連付けます。

トップに戻る

DSMエディターの開始と使用

DSM エディターには、「ログ・アクティビティー 」タブからも「管理」タブからもアクセスできるため、イベント変更への対応が行いやすくなっています。

DSM エディターには以下のいずれかの方法で開始します。

「≡」メニューから「管理」をクリックします。

ナビゲーション・メニューで、「データ・ソース」 > 「DSM エディター」をクリックします。

または

「ログ・アクティビティー」タブをクリックします。

1 つ以上のイベントを選択します。

ナビゲーション・メニューで、「アクション」 > 「DSM エディター 」を選択します。

この方法は、既に作成したカスタムDSMから漏れていたログ形式を追加定義する場合などに便利です。

※上図は参考情報です。QRadar CEではヒストリカル相関を利用できません。

トップに戻る

サンプル・ログについて

今回使用するサンプル・ログは、以下からダウンロードすることができます。
UTF-8でエンコードされており(BOMなし)、行末はLFです。
SampleLog.log

カスタム・ログのDSM定義を行う場合、存在するログ形式のパターンを全て拾い出すことが重要です。
このサンプル・ログには、以下の 4種類 のログ形式が混在して含まれています。

2020/10/20 23:22,認証プロセス,[548],認証の試行 username=user name パスワードは正しいが不正なホスト ip=172.30.34.90 2020/10/20 23:23,認証プロセス,[18060],認証の成功 username=user name ip=172.30.34.90 port=53026 2020/10/20 0:30,認証プロセス,[9279],セッション・オープン username=user name 2020/10/20 0:30,認証プロセス,[9279],セッション・クローズ username=user name

ヒント：実際のシステムから出力されるログのパターンは、もっと多いことが考えられます。そのため、最初に全てのパターンを洗い出せないかもしれません。正規化のマッピングが行われていないログは、「Unknown」という特別なカテゴリーとして記録されます。検索でこのカテゴリーに絞り込んだり、アラートすることもできるため、QRadarを運用しながら未知の形式を継続的にDSMエディターで追加定義することで、カスタムDSMを洗練させていくことができます。

サンプル・ログが正規化されるまでの流れは、下図の通りです。



一見すると少し複雑ですが、これらは全てDSMエディターのGUIで設定するため、XML定義や依存関係などを個別に作成・編集する必要はありません。

トップに戻る

演習1：カスタムDSMの作成

カスタム・ログのDSMを作成するにあたって、最初に専用のログソース・タイプを作成します。
次に、サンプル・ログの内容をDSMエディターに読み込ませ、必須とオプションのプロパティーを、画面で確認しながら切り出します。
最後に、切り出したログ形式ごとに正規化したイベントをマッピングし、相関分析での利用に適した構成を行います。

トップに戻る

1-1：ログソース・タイプの作成

最初に、専用のログソース・タイプを作成します。
「Universal DSM」というタイプをそのまま利用することもできますが、フィルターの柔軟性やパフォーマンス・チューニングの観点で、推奨ではありません。

「DSMエディターへのアクセスと使用」で説明した方法のうち、1つ目の「「≡」メニューから「管理」をクリック」する方法でDSMエディターを開始します。

「ログソース・タイプの選択」が表示されますので、「新規作成」をクリックします。

「ログソース・タイプ名」に、TrainingSampleLog (※)と入力します。

※注意： もし、この演習を行わず、下記のカスタムDSM定義をそのままインポートしたい場合は、TrainingSampleLog という名前は使わないでください。QRadarに既に同じ名前のログソース・タイプ名がある場合、インポートは失敗します。 DSMエディターで作成済みの定義サンプルを使用するには、以下のファイルをダウンロードし、「≡」メニューから「管理」をクリックし、「システム構成」 > 「拡張の管理」 から「追加」することでインポートできます。 TrainingSampleLog-20201107164146.zip ※IBMが正式に公開しているコンテンツではないため、インポート時に署名のエラーが出ます。 ヒント： 同じ理由から、(今は存在しなくても)IBMまたは各ベンダーが正式にDSMを提供した場合に使いそうなログソース・タイプ名は、カスタムDSMのログソース・タイプ名として避けることをおすすめします。例えば接頭辞として組織名を入れるなど、衝突の可能性を低くしてください。

元の画面にリストされている、作成したばかりの TrainingSampleLog を選び、「選択」をクリックします。



DSMエディターが開きます。



次のステップに進む前に、「ワークスペース」にサンプル・ログのサンプリング情報を貼り付けておきましょう。

右上の「✎」鉛筆マークをクリックして編集状態にし、以下のテキストをコピー・アンド・ペーストして、「✔」チェックマークをクリックします。

<182>Nov 07 16:39:38 1.1.1.1 2020/10/20 23:22,認証プロセス,[548],認証の試行 username=user name パスワードは正しいが不正なホスト ip=172.30.34.90 <182>Nov 07 16:39:39 1.1.1.1 2020/10/20 23:23,認証プロセス,[18060],認証の成功 username=user name ip=172.30.34.90 port=53026 <182>Nov 07 16:39:40 1.1.1.1 2020/10/20 0:30,認証プロセス,[9279],セッション・オープン username=user name <182>Nov 07 16:39:41 1.1.1.1 2020/10/20 0:30,認証プロセス,[9279],セッション・クローズ username=user name

上記と同じ内容をテキスト・ファイルで入手するには、サンプル・ログのサンプリング からダウンロードしてください。


これにより、下段の「ログ・アクティビティーのプレビュー」欄に、1行 = 1レコード としてプレビューされます。

ヒント： 「ワークスペース」にサンプル・ログのサンプリング情報を貼り付ける際には、最後の行の末尾に改行を入れるようにしましょう。プロパティーを正規表現で切り出す場合など、行末かどうかの判断に影響がある可能性があります。 「サンプル・ログについて」で示したログ・サンプルを、そのままDSMエディターのサンプリング情報として使用することもできますが、実際のログをSyslogで受け取る場合、ペイロードにはSyslogヘッダーが付くことに注意が必要です。画面上で行頭であったところが実際のペイロードでは行頭ではなかったりするなど、正規表現の記述に影響がある可能性があります。 Syslogヘッダー部分はダミーでもよく、例えばテキスト・エディターで <182>Nov 07 16:39:38 1.1.1.1 (最後は半角スペース) を各行の先頭に付けることでも対応できます。

トップに戻る

1-2：標準プロパティーとカスタム・プロパティーの切り出し

今回は、4種類のログ形式を含むサンプル・ログから、以下のプロパティーを切り出します。

種別	プロパティー名	サンプル・テキスト	式のタイプ	定義内容の例	説明
標準プロパティー	ログ・ソースの時刻	2020/10/20 23:23	正規表現	式：(\d{4}/\d{1,2}/\d{1,2} \d{1,2}:\d{1,2}), フォーマット設定ストリング：$1 日付形式：yyyy/MM/dd hh:mm
	イベントID ★	認証の成功 認証の試行 セッション・オープン セッション・クローズ	正規表現	式：,.*,.*,(.*?)\susername= フォーマット設定ストリング：$1	1つのログ形式ごとに、その形式を代表するユニークな値を特定する必要があります。
	イベント・カテゴリー ★	認証プロセス	ジェネリック・リスト(CSV)	式：$1 区切り文字：,	ログにカテゴリーに相当する文字列がある場合はそれを切り出します。特にない場合は、ログソース全体で1つのカテゴリーしかないDSMも多いため、固定文字列を返すように指定しても構いません。
	ユーザー名	user name	1: 正規表現	式：username=([\w\s]+)$ フォーマット設定ストリング：$1	行末にユーザー名が位置するパターン用です。
			2: 正規表現	式：username=([\w\s]+)\s フォーマット設定ストリング：$1	行の途中にユーザー名が位置するパターン用です。
	送信元IP	172.30.34.90	正規表現	式：ip=([0-9.:]*) フォーマット設定ストリング：$1
	送信元ポート	53026	正規表現	式：port=(\d{1,5}) フォーマット設定ストリング：$1
カスタム・プロパティー	AuthProcessId	18060	正規表現	式：,.*,\[(.*)], キャプチャー・グループ：1

トップに戻る

正規表現の切り出し方

上の表にリストされた切り出したいプロパティーを、順に定義します。

標準プロパティーはあらかじめ「プロパティー」タブに含まれているため、スクロールするかフィルター入力域にプロパティー名の一部を入力して絞り込みます。
目的のプロパティーが見つかったら(下図の例では「ログ・ソースの時刻」)、「システム動作のオーバーライド」にチェックを付けます。

「式のタイプ」から「正規表現」を選択し、「式」に正規表現を記述し、「フォーマット設定ストリング」に正規表現のキャプチャー・グループに対応した変数を指定します。

「ログ・ソースの時刻」は日付タイプであるため、「日付形式」として、元のイベントで表示される日時の形式に一致するパターンを指定する必要があります。
例えば、「Apr 17 2017 11:29:00」の場合、有効な日時のパターンは「MMM dd YYYY HH:mm:ss」になります。
日付形式の指定について詳しくは、Java Web ページ にある SimpleDateFormat の情報を参照してください。

「OK」をクリックすると、「ログ・アクティビティーのプレビュー」欄に、「ワークスペース」に貼り付けたサンプル・ログの値が反映されます。

ヒント： プレビューに値が反映されていない場合は、定義に何らかの問題がある可能性があり、そのまま「保存」しても実際のログを正しくパーシングできません。

トップに戻る

複数の式を定義する方法

1つの式で全てのログ形式のパターンをカバーできない場合は、緑色の「＋」ボタンをクリックすることで、複数の式を指定することができます。

先にマッチした値が使用されますので、各ログ形式が複数の式にマッチする場合は、定義順序が重要になる場合があります。
式のタイルを上下にドラッグすることで、定義後も順序を変更できます。


トップに戻る

ジェネリック・リスト(CSVなど)の定義方法

ジェネリック・リストの代表例はCSVです。
切り出したいカラム位置を指定する式と区切り文字を指定することで、値を取り出すことができます。



トップに戻る

カスタム・プロパティーを追加する方法

「プロパティー」タブにはあらかじめ標準プロパティーが追加されていますが、カスタム・プロパティーも手動で追加することができます。

まず、「プロパティー」タブのフィルターの横にある「＋」をクリックします。
表示された「カスタム・プロパティー定義の選択」画面の下部にある、「新規作成」をクリックします。

「名前」に「AuthProcessId」を入力し、「保存」をクリックします。



カスタム・プロパティーが追加された後は、標準プロパティーとほぼ同様に定義を行うことができます。

トップに戻る

1-3：イベント・マッピングの作成

プロパティーを切り出して固有のイベントが定義された後は、それらをイベント名、上位/下位カテゴリーにマッピングする必要があります。
今回は、4種類 のログ形式を含むサンプル・ログですので、固有のイベントも 4種類 あります。

イベントID	イベント・カテゴリー	イベント名 (QIDごとにユニーク)	上位カテゴリー(HLC)	下位カテゴリー(LLC)	重大度
認証の試行	認証プロセス	General Authentication Failed	認証	失敗した一般認証	3
認証の成功	認証プロセス	General Authentication Successful	認証	成功した一般認証	1
セッション・オープン	認証プロセス	Auth Server Session Opened	認証	開かれた認証サーバーのセッション	1
セッション・クローズ	認証プロセス	Auth Server Session Closed	認証	閉じられた認証サーバーのセッション	1

トップに戻る

イベント・マッピングの定義方法

DSMエディターの「イベント・マッピング」タブから、QID にマッピングすべき「イベント ID」 と「イベント・カテゴリー」の組み合わせを入力します。
これにより、ルールなどの作成に使用できるシステムが確認したイベントに、メタデータを提供できるようになります。

「＋」マークをクリックして「新規イベント・マッピングの作成」画面を表示し、「イベントID」と「イベント・カテゴリー」を入力して「QIDの選択」をクリックします。



QIDは、新規に作成することも、既存のイベントから選択することもできます。

「QIDレコード」画面の上部にある「上位カテゴリー」「下位カテゴリー」「ログ・ソース・タイプ」は、ドロップダウン・リストです。キーワードを入力することで絞り込むことができます。

「QID/名前」には、直接キーワードを入力することで、「検索」をクリックした際の結果を絞り込むことができます。
目的にあったイベントを特定したら、それを選択した状態で「OK」をクリックします。

今回は新規イベントを作成しますので、「新しいQIDレコードの作成」をクリックします。


「QIDレコード」画面で、新規イベントを作成します。

まず、「名前」と「説明」を入力します。
「Universal DSM」など既存DSMに関連付けられた定義済みイベントが参考になります。

次に、「ログ・ソース・タイプ」として、編集中の TrainingSampleLog が選択されていることを確認します。

「上位カテゴリー」と「下位カテゴリー」を割り当てます。
こちらも、「Universal DSM」など既存DSMに関連付けられた定義済みイベントが参考になります。

ヒント：Universal DSMに定義されているイベントやカテゴリーについては、Universal_DSM.csv を参照してください。

最後に「重大度」(10段階) を割り当てたら、「保存」をクリックします。



「QIDレコード」画面に、作成したばかりの新しいQIDレコードが表示・選択されますので、「OK」をクリックします。



その後、「新規イベント・マッピングの作成」画面が出ますので、「作成」をクリックします。



この作業を、ユニークなログ形式の数 (合計4回) 繰り返すことで、イベント・マッピングが完了します。

「ログ・アクティビティーのプレビュー」が更新され、各ログ形式に対応する「イベント名」と関連する「下位カテゴリー」の列に、設定した値が表示されていることがわかります。



最後に「保存」をクリックして、DSMエディターを終了します。

トップに戻る

演習2：カスタムDSMのテスト[検索編]

作成したばかりのカスタムDSMが機能していることを確認しましょう。
SampleLog.log をダウンロードし、QRadar CEにSyslog形式で送信します。

トップに戻る

2-1：ログソースの定義

QRadarにはログソースの自動認識・作成機能がありますが、今回作成したカスタムDSMには自動認識の設定をしていません。
そのため、まずログソースの定義を作成します。

「≡」メニューから「管理」をクリックします。

ナビゲーション・メニューで、「データ・ソース」 > 「ログ・ソース」をクリックします。

「追加」をクリックし、以下を入力します。

ログ・ソース名	TrainingSample (任意の名前)
ログ・ソースの説明	任意の説明
ログ・ソース・タイプ	TrainingSampleLog (DSMエディターで作成したログソース・タイプの名前)
プロトコル構成	Syslog (未文書化と表示されることがありますが、問題ありません)
ログ・ソース ID	1.1.1.1 (任意のIPアドレス。logrun.pl などログ送信ツールの指定と合わせます)
有効	✔
イベントの統合	チェックを外してください。 (テストで確認しやすくするため)
受信ペイロードのエンコード	UTF-8
イベント・ペイロードの保管	✔
ログ・ソース拡張	TrainingSampleLogCustom_ext (DSMエディターで作成したログソース・タイプに対応するもの)

「管理」画面に、「⚠ デプロイされていない変更があります。 「変更のデプロイ」をクリックしてそれらをデプロイしてください。」という警告が表示されますので、「変更のデプロイ」をクリックしてログソースの追加をシステムに反映させてください。

トップに戻る

2-2：サンプル・ログの再生

サンプル・ログを再生すると、「ログ・アクティビティー」タブに正規化されたイベントが表示されます。
しかし、QRadar自身の管理イベントも多く流れているため、ごくわずかなイベントを見逃してしまうかもしれません。

そのため、事前準備としてフィルターを設定しておくことをおすすめします。

トップに戻る

フィルター設定

まず、「ログ・アクティビティー」タブを表示します。

「フィルターの追加」をクリックし、以下を入力します。

• パラメーター：ログソース[索引付き]
• 演算子：次と等しい
• 値：ログ・ソース：TrainingSample (ログソース定義で指定した任意の名前)

以後「ログ・アクティビティー」タブには、今回追加したカスタムDSMのログのみが表示されます。

トップに戻る

サンプル・ログの再生方法

サンプル・ログの再生には、いくつか方法があります。

1つ目は、「SIEM学習に最適な QRadar Experience Center アプリでユースケースを流してみましょう」でご紹介した Experience Centerアプリに備わっている、ログのアップロード&再生機能です。

Experience Center アプリの「↑ Upload logs to QRadar」というメニューを選択すると、「Select File」ボタンのクリックで任意のログファイルをアップロードできますので、SampleLog.log をアップロードします。

アップロード後、「Next」をクリックして次の画面に遷移すると、アップロードしたログを再生できる「▶」ボタンがあります。
ログソースID (Log Source Identifier) を指定できますので、ここでログソース定義で指定したものと同じIPアドレスを指定してから再生してください。



学習用のアプリであるため、ログの再生レートは比較的遅く設定されており、テンポよくテストを進めたい場合は、次の logrun.pl の方がよいかもしれません。

トップに戻る

2つ目の方法である logrun.pl は、QRadar CEに内蔵されているスクリプトです。

logrun.plの構文は、以下の通りです。

/opt/qradar/bin/logrun.pl [-d <host>] [-p <port>] [-f filename] [-u <IP>] [-l] [-t] [-b] [-n NAME] [-v] <messages per second> -d : 送信先のsyslogホスト（デフォルトでは127.0.0.1） -p : 送信先ポート（デフォルトでは514） -f : 読み取るファイル名（デフォルトではreadme.syslog） -b : 遅延時間の20%に同じメッセージをバースト -t : syslogsを送信するためにUDPではなくTCPを使用 -v : ファイルから読み取る行の詳細を表示 -n : NAMEをsyslogヘッダーのオブジェクト名として使用 -l : 無限ループ -u : 詐称発信者としてIP を使用（デフォルトではIP ヘッダーを送信しない）

まず、WinSCPなど任意のSSH対応ファイル転送ツールで、SampleLog.log をQRadar CE本体に転送します。
使用するディレクトリーは任意ですが、/root などが使用できます。

次に、PuTTY や Tera Termなどの任意のSSHターミナル・ソフトを使用して QRadar CEコンソールにログインし、/opt/qradar/bin/logrun.pl コマンドを発行します。

[root@qce1 ~]# ls -l *log -rw-r--r-- 1 root root 13831 Nov 7 06:54 SampleLog.log [root@qce1 ~]# /opt/qradar/bin/logrun.pl -u 1.1.1.1 -l -f SampleLog.log 1 generating 1 messages per second to 127.0.0.1:514 Ctrl-c to stop

上の例では、ログソースID 1.1.1.1 付き (-u オプション) の Syslogメッセージを、1秒に1件ずつ QRadar自身に無限ループ (-l オプション) で送信します。

これにより、「ログ・アクティビティー」タブには、以下のようなカスタムDSMの正規化されたメッセージが表示されます。



次のログ検索に使用しますので、しばらく(数分間ほど)ログを流し、QRadarにイベントを蓄えてください。

その後、Ctrl-C で logrun.plを止めてください。

トップに戻る

2-3：ログの検索とグラフ化

QRadarの検索機能は幅広いため、ここで全てを説明することは不可能です。
そのため、最も基本的なフィルタリングのみを扱います。
詳しくは参考文献に挙げたマニュアルのリンクなどを参照してください。

ここまでの手順で、現在「ログ・アクティビティー」タブには、作成したばかりのカスタムDSMのログだけが表示されるようになっています。
この状態で上部の「クイック・フィルター」にキーワードを入力すると、既に適用されているフィルターの範囲内で絞り込み検索が行われます。

まず「ビュー」の選択で、「過去15分間」などを選択してリアルタイム・ストリーミング再生を停止してください。
次に、「クイック・フィルター」に、「試行」と入力して「検索」をクリックしてください。



これにより、既に適用されていたログソースの絞り込みに加えて、ペイロードに「試行」という文字が含まれるログのみがリストされました。

次に、「表示」を「ユーザー名」に設定します。
また、グラフが非表示の場合は、「グラフの表示」をクリックしてください。

ヒント： もし何もヒットしなかった場合は、時間が経過して過去15分以内のログがなくなったのかもしれません。 その場合はもっと過去の時間まで含むように「ビュー」の選択を変更してください。

これにより、「試行」を含むログを「ユーザー名」ごとにグループ化し、件数の多いものから順にグラフ化することができました。
プロパティーとしてユーザー名を切り出しておいたおかげで、このような切り口の可視化が容易に行なえます。

次に、「検索」メニューから「検索の編集」を行い、検索条件の変更と、検索結果に表示するプロパティーの追加を行います。

クイック・フィルターはログに含まれる文字列に依存するため汎用性がありませんので、それを削除し、代わりに「カテゴリー」が「失敗した一般認証」であるという条件を追加します。

そして、今回のカスタムDSMで追加した「AuthProcessId」というプロパティーを、検索結果に含めるように「＞」をクリックして「列」に追加し、「↑」を複数回クリックして一番上に置きます。



「検索」をクリックすることで、変更された条件に基づく検索結果が表示されます。



今後もこの条件の検索がいつでもできるように、「条件の保存」をクリックします。

①「検索名」を設定し、各種オプションを指定して、最後に「OK」をクリックします。
②「クイック検索に含める」にチェックを入れておくと「クイック検索」メニューに追加され、「検索」メニューから呼び出さなくても、すぐに検索できるようになります。



トップに戻る

2-4：AQLによる拡張検索の使用

Ariel 照会言語 (AQL) は、QRadarが収集したログやフローを格納しているAriel データベースと通信するために使用する構造化照会言語です。
AQL を使用して、Ariel データベースのイベント・データやフロー・データを照会します。SQLに類似の言語ですが、照会のみで更新や削除はできません。

コンソールで検索やルール条件に使用するほか、REST APIからもAQLを使用したイベントやフローの検索が可能です。

AQLは非常に幅広い機能を持つため、ここで全てを説明することはできません。
末尾の参考文献の中に、AQLに関する資料へのリンクも含まれていますので、ぜひご確認ください。

AQLの基本的な構造は、以下の通りです。


以下にAQLの一例を示します。

SELECT DATEFORMAT(starttime,'yyyy/MM/dd HH:mm:ss z') as 'Start Time', sourceip, destinationip, CATEGORYNAME(category) as 'Category', QIDDESCRIPTION(qid) as 'Event Name', username FROM events WHERE LOGSOURCENAME(logsourceid) ilike '%Training%' LAST 1 HOURS

主な構文は以下の通りです。
(全てを網羅していませんので、参考文献や製品のマニュアルを参照してください)

構造	説明
SELECT ... FROM	AQLはSELECTからはじめ、イベントの場合は FROM events、フローの場合は FROM flows を記述します。
WHERE ...	検索条件を絞ります。 比較演算子は =, !=, <, >, <=, >= 論理演算子(AND/OR/NOT)で複数の条件を記載できます。 プロパティーのNULL値チェックは IS NULL / IS NOT NULL 値の範囲はBETWEEN A AND B A以上B以下の意味となり、AおよびBの値も含まれます。
期間の指定	期間を指定しないと直近5分間のイベント/フローが検索対象となります。 期間指定はQRadarのイベント受信時間(starttime)に対して行われます。ログソース時間(devicetime)ではないことに注意してください。 検索期間指定はAQLの一番最後に記載します。 START/STOPによる指定 START 'YYYY-MM-dd HH:mm' STOP 'YYYY-MM-dd HH:mm' LASTによる指定 LAST [数字] MINUTES/HOURS/DAYS 1であっても複数形　LAST 1 HOURS
日時のプロパティー	日時関連のプロパティーはUNIXタイムスタンプの形式で管理されているため、通常は整形して使用します。 DATEFORMATによる整形 DATEFORMAT(プロパティー名, 'フォーマットパターン文字') フォーマットパターン文字の例： HH:mm:ss dd-MM-YYYY → 04:19:22 10-12-2014 YYYY/MM/dd HH:mm:ss → 2014/11/08 04:19:11 YYYY/MM/dd a hh:mm → 2014/11/08 AM 04:19
LIKE/ILIKE '検索条件'	あいまい検索を行います。 %がワイルドカードとなります。 ILIKEは大文字/小文字を区別しません。
MATCHES/IMATCHES '検索条件'	正規表現を使った検索を行います。 正規表現によりLIKEより自由度の高い記述が可能です。 IMATCHESは大文字/小文字を区別しません。
TEXT SEARCH '検索文字列'	「クイック・フィルター」とおなじように、テキスト検索が可能です。 WHERE条件の最初に記述する必要があります。 WHERE条件でTEXT SEARCH以外の条件と組み合わせる場合は、AND条件しか使えません。
集計	GROUP BY 指定したプロパティーで集約します。 COUNT/UNIQUECOUNT レコード数を集計します。 COUNT(*)の場合はレコード総数を取得します。COUNT(プロパティー名）でプロパティーが存在するレコード総数を取得します。 UNIQUECOUNT(プロパティー名）でプロパティー値の重複を除いた数を取得します。
ORDER BY ...	表示順序を指定します。 降順（デフォルト) ORDER BY [プロパティー or エイリアス名]　ASC 昇順 ORDER BY [プロパティー or エイリアス名]　DESC
LIMIT	LIMIT [数字] の形式で指定し、結果の取得数を制限します。
文字列操作	STR 指定した引数を文字列に変換します。 STRLEN 文字列の長さを返します。 STRPOS 指定した文字列が、もとの文字列の何バイト目に含まれるかを返します。存在しない場合は-1を返します。 SUBSTRING(string,m,n) 指定した文字列のm番目からn番目までを切り出します。 UPPER 指定した引数の大文字を返します。 LOWER 指定した引数の小文字を返します。 CONCAT 指定した引数をすべて連結した文字列にします。 BASE64 文字列をbase64エンコードします。 UTF8 指定した引数をUTF8文字列に変換します。 REPLACEALL(正規表現、変換対象プロパティ、変換後の文字列) 正規表現にマッチしたすべてを置換します。 REPLACEALL(正規表現、変換対象プロパティ、変換後の文字列) 正規表現にマッチしたはじめの文字だけ置換します。

一般にAQLでよく使われるプロパティーや関数を以下に示します。

プロパティー名	説明
sourceip	送信元IP
sourceport	送信元ポート
destinationip	宛先IP
destinationport	宛先ポート
username	ユーザー名
qidname(qid) qiddescription(qid)	イベント名/イベントの説明に相当 (QIDはID番号でありそのままでは見づらいので、名前や説明に変換する関数を呼び出しています)
logsourcename(logsourceid) logsourcegroupname(logsourceid) logsourcetypename(logsourceid)	ログソース名/ログソース・グループ/ログソース・タイプに相当 (logsourceidはID番号でありそのままでは見づらいので名前に変換したり、所属するグループやタイプを特定して名前を表示する関数を呼び出しています)
categoryname(category) categoryname(highlevelcategory)	LLC(下位カテゴリ)名/HLC(上位カテゴリ)名に相当 (category/highlevelcategoryはID番号でありそのままでは見づらいので、関数で名前に変換しています)
DATEFORMAT(starttime,’YYYY-MM-dd HH:mm:ss’) DATEFORMAT(devicetime,’YYYY-MM-dd HH:mm:ss’)	ログの受信時間/デバイスのログ時間(YYYY-MM-dd HH:mm:ss形式) starttimeは QRadarがログを受信した際に自動的に付与されるタイムスタンプ、devicetimeはログのペイロードから切り出したタイムスタンプです。
eventcount	イベントの数。通常は1。イベントの統合がONになっている場合は統合されたイベント数。

① QRadarコンソールからAQLを使用する場合、「ログ・アクティビティー」タブで「拡張検索」を選択します。
② 次に、入力欄にAQLを入力します。自動補完やエラー表示など、GUIに支援機能があります。
③ 最後に「検索」をクリックすると、④ 結果が表示されます。



トップに戻る

2-5：AQLによる拡張検索とリファレンス・セット

QRadarには、リファレンス・セットという機能があり、AQLからもアクセスすることができます。
リファレンス・セットを使用して、シンプルなリスト形式でデータを保管できます。

ヒント： QRadarには、リファレンス・セットの他にも、リファレンス・マップやリファレンス・テーブルなど、もっと複雑なデータを扱える機能があります。 詳しくは、製品マニュアル「リファレンス・データ収集のタイプ」を参照してください。

侵害の痕跡 (IOC) データなどの外部脅威データをリファレンス・セットに取り込むことも、ネットワークで発生したイベントおよびフローから収集されたビジネス・データ (IP アドレス、ユーザー名など) を保管するためにリファレンス・セットを使用することもできます。

ここでは、簡単な例として「TrainingSampleUsers」というリファレンス・セットを作成します。

①「≡」メニューから「管理」をクリックします。
ナビゲーション・メニューで、「システム構成」 > 「リファレンス・セット管理」をクリックします。

②「追加」をクリックすると、「新規リファレンス収集」画面が開きます。
③「名前」に「TrainingSampleUsers」、「タイプ」に「英数字(大/小文字は無視)」、「エレメントの存続時間」の「日数」の部分に「1」を入力し、「作成」をクリックします。

④リファレンス・セットを作成したら、そのリファレンス・セットの画面の中の「追加」をクリックします。
⑤「リファレンス・セット・データの追加」画面が開きますので、「値」に「root,super,admin」、「分離文字」に「,」(カンマ)を入力し、「追加」をクリックします。

⑥ここまでの手順で、以下の図の右下にあるように、「値」に3行が追加された状態になります。

リファレンス・セットの準備が整ったら、「ログ・アクティビティー」タブに戻り、以下のAQLを入力します。

SELECT DATEFORMAT(starttime,'yyyy/MM/dd HH:mm:ss z') as 'Start Time', sourceip, destinationip, CATEGORYNAME(category) as 'Category', QIDDESCRIPTION(qid) as 'Event Name', username FROM events WHERE LOGSOURCENAME(logsourceid) ilike '%Training%' AND REFERENCESETCONTAINS('TrainingSampleUsers', REPLACEFIRST('(\w+)\s\w*', username, '$1')) LAST 1 HOURS

1つ前の演習で使用したAQLのWHEREに、新たな条件としてREFERENCESETCONTAINSが追加されています。
この関数は、第1引数で指定したリファレンス・セット内に第2引数で指定した値が含まれているかどうかを検査し、真偽を返します。

この例では、usernameをそのまま渡すのではなく、REPLACEFIRSTを使用して空白で区切られた前の部分の文字列のみを取り出す正規表現を適用しています。



この演習では、単純化するためにWeb UIからリファレンス・セットのデータを入力しましたが、実用的な実装ではログ収集において特定のルールにマッチした場合のプロパティーを自動的に収集したり、外部の脅威インテリジェンス情報をREST APIで与えたりします。

リファレンス・セットは、AQLによるアドホックな検索だけでなく、相関分析ルールの中で活用することも可能です。

比較的わかりやすい実装例が、ブログ「SIEM学習に最適な QRadar Experience Center アプリでユースケースを流してみましょう」で説明されていますので、ご興味のある方はぜひそちらもご覧ください。以下に図解のみ引用しておきます。



トップに戻る

演習3：カスタムDSMのテスト[相関分析編]

ここまで、カスタムDSMを作成し、テキストログを正規化して取り込み、そのログを検索したりグラフ化する手順を見てきました。

しかし、ここまでの処理はいわゆる「SIEM」というよりは、「ログ管理ツール」という印象だったのではないでしょうか。
正規化はともかく、集めて検索してグラフにするだけならば、データ量が膨大にならなければ表計算ソフトでもできそうに思えます。

そこで最後に、ここまでの過程で意識せずに使っていた、QRadarのSIEMとしての側面をご紹介しましょう。

トップに戻る

3-1：生成されたオフェンスの確認

今回のカスタムDSMは、QRadarの正規化された認証イベントの範囲内で制作したものであるため、標準実装されている相関分析ルールで処理されます。
独自のログであるにもかかわらず、IBMやベンダーが提供したログソースと同様に既存ルールを活用できるのは、正規化されている強みです。

「オフェンス」タブをクリックして、オフェンス一覧を表示してください。
恐らく、これまでの logrun.plなどによるサンプル・ログのテストにより、複数のオフェンスが上がっているのではないでしょうか。



この中の1つを開いてみると、logrun.plで流した大量のイベントが、オフェンスという1つの関連性の中でまとめられ、ユーザーが調査しやすいように集約されていることがわかります。オフェンスの仕組みで関連するイベントをまとめてくれていなければ、もっと多くの重複するアラートが上がっていたことになります。




トップに戻る

3-2：標準ルールの内容

オフェンスに貢献したルールは、各オフェンスの画面から「表示」＞「ルール」で確認できます。



例示しているルールは、「認証失敗」という「ビルディング・ブロック」(ルールのサブ要素) にログのイベントがヒットし、かつ、各イベントに含まれる「ユーザー名」プロパティーで、同一ユーザー名が 5分間に 10件以上観察された場合にトリガーされるものです。

ルール定義の中でハイパーリンクになっている箇所は、チューニングのために変更可能な部分であり、環境に合わせて調整できます。

QRadarでは、蓄積されたログに対して様々な検索ができることはもちろんですが、上記のようなルールが多数有効化され、リアルタイムで入ってくるログに対して常に目を光らせています。ルールは App Exchange で多数公開されていますので、必要なものを取り込んで増強できますし、必要であればカスタム・ルールを作ることもできます。

トップに戻る


参考文献

• QRadar CE (Community Edition) 7.3.3 のインストール手順を日本語でご紹介します
• SIEM学習に最適な QRadar Experience Center アプリでユースケースを流してみましょう
• QRadar CE (Community Edition) 7.3.3 で Windows 10 Pro のライブイベントを取得してみる
• SimpleDateFormat (Java Platform SE 8 )
• QRadar でのイベント・データの処理
• イベントとフローの検索
• Ariel 照会言語
• QRadar Open Mic #12: Using AQL in Advanced Searches - 13 April 2016 [Replay available]

#QRadar