セキュリティイベント (SIEM)

Status200 はセキュリティイベントをログ、トレース、メトリクスと並べて保持し、どの形式で届いたかにかかわらず、すべてを同じ形 OCSF (Open Cybersecurity Schema Framework) にそろえます。あらゆるソースからイベントを送り、検索し、重要なものを Sigma 検出ルール、脅威インテリジェンス、モニターで見つけましょう。見つかったものは対応すべき ケース になり、プレイブックがそれに対応します。

仕組み#

オブザーバビリティ の下にある 製品 → セキュリティイベント を開きます。メニューには、セキュリティの部分ごとのセクションと、その中の項目ごとの独立したページがあります。

一度設定すれば済む 検出 、 AI と 接続 は、開くまで折りたたまれています。セキュリティを初めて使う場合は、セキュリティをはじめる でクリック 2 回で設定できます。

始める前に#

セキュリティデータを読めるのは、Project Owner と Project Admin のロール、そして 3 つの Security ロールだけです。それ以外のロールには、セキュリティイベントに何も表示されません。 ロール を参照してください。

セキュリティイベントを送る#

1. 取り込みキーを作成する#

   プロジェクト設定 → テレメトリと APM → 取り込みキー を開き、 取り込みキーを作成 をクリックします。セキュリティイベントは、ほかのテレメトリと同じキーを使います。

2. イベントを送信する#

   キーを x-status200-token に入れて、JSON を /security-events/v1/ingest に送ります。

   OCSFGoogle UDMGeneric JSON

   OCSF

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=ocsf" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -H "x-status200-service-name: my-security-source" \
     -d '{ "events": [ { "class_uid": 3002, "severity_id": 4, "status": "Failure", "message": "Failed logon for alice", "actor": { "user": { "name": "alice" } }, "src_endpoint": { "ip": "203.0.113.7", "hostname": "laptop-alice" } } ] }'

   Google UDM

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=udm" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "metadata": { "event_type": "USER_LOGIN" }, "principal": { "hostname": "laptop-alice", "user": { "userid": "alice" }, "ip": ["203.0.113.7"] }, "security_result": [{ "severity": "HIGH", "action": ["BLOCK"] }] } ] }'

   Generic JSON

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "severity": "high", "event_type": "ssh_brute_force", "message": "12 failed SSH logins in 60s", "username": "root", "hostname": "web-01", "src_ip": "203.0.113.7" } ] }'

   イベントがキューに入ると、エンドポイントは 200 を返します。これらのように時刻なしで送ったイベントは、届いた時点に置かれます。

3. イベントタブで見つける#

   製品 → セキュリティイベント → イベント を開きます。数秒以内にイベントが表示され、重大度、クラス、ユーザー、ホスト、IP アドレスが入力されています。

形式#

形式は ?format=、 x-oneuptime-security-event-format ヘッダー、または最上位の "format" フィールドで指定します。指定しなければイベントごとに形式が判定されるので、ひとつの Webhook で検出と生のイベントを混在させることができます。

• 本文は、ひとつのイベント、イベントの配列、または { "events": [...] } のいずれかです。
• x-status200-service-name ヘッダーは、イベントが属するテレメトリサービスを指定します。指定しなければ、最初のイベントの製品名またはベンダー名にちなんだサービス、または Security Events に属します。
• 対応付けられなかったものも破棄されません。ソースのすべての項目がイベントの属性に入ります。

汎用 JSON の項目#

汎用のイベントは、一般的な項目名で読み取られます。

重大度を表す語は OCSF のレベルに変換されます。 info は Informational、 warning は Low、 error は Medium、 alert は Critical、 emergency は Fatal として読み取られます。

Fluent Bit で転送する#

auditd、syslog、Falco など、すでに収集しているセキュリティログを送るには、Fluent Bit に http 出力を追加します。

[OUTPUT]
    Name             http
    Match            security.*
    Host             status200.ru
    Port             443
    tls              On
    URI              /security-events/v1/ingest
    Format           json
    Json_date_key    timestamp
    Json_date_format iso8601
    Header           x-status200-token YOUR_INGESTION_TOKEN
    Header           x-status200-service-name my-security-source
    Retry_Limit      5

接続 の下にある セットアップガイド ページには、ホストとキーが入力済みのこれらのスニペットがあります。

ログからセキュリティイベントを見つける#

接続 の上部にある ログ は、すでに Status200 に送っているログをソースにします。ログからセキュリティイベントを見つける を有効にすると、プロジェクトの新しいログが毎分読み取られ、そこに含まれる SSH サインイン、sudo コマンド、Kubernetes の監査レコード、AWS CloudTrail の変更、Web 攻撃がそれぞれセキュリティイベントとして保存されます。種類ごとの内容は セキュリティをはじめる を参照してください。

セキュリティ製品を接続する#

接続 は、セキュリティ製品をあなたの代わりにポーリングし、その新しいレコードをセキュリティイベントとして取り込みます。接続は製品の設定と暗号化された認証情報を保持し、ワーカーが設定した間隔でポーリングして、取り込み済みのレコードはスキップします。

• 製品自身のアラートのうち Open Cases From (別のレベルを選ばない限り 高以上、または なし) 以上のものは、対象のユーザー、ホスト、アドレスごとにまとめられて ケース を開きます。
• 接続は、レコードが表すアクティビティの時刻ではなく、製品がレコードを作成した時刻で読み取ります。1 時間ごとに実行される SIEM ルールは一致したイベントよりずっと後に検出を作成しますが、それも取り込まれます。
• 最初のポーリングは 24 時間さかのぼるので、新しい接続ではすぐに最近のレコードが表示されます。
• 接続の行にある 接続をテスト は、製品へのアクセスと Status200 自身のワーカーが動いているかを確認し、何も取り込みません。 今すぐ実行 はすぐにポーリングします。

イベントが持つもの#

すべてのイベントは、型付きの項目とソースのペイロードとともに保存されます。

セキュリティイベントを調べる#

イベント は、ログやトレースのエクスプローラーと同じテレメトリエクスプローラーです。ウィンドウ内のイベントを重大度別に示すグラフ、ファセットのサイドバー、一覧、そして開いたイベントのすべての項目と属性を表示するパネルがあります。ウィンドウ、フィルター、検索はすべて URL に保存されるので、絞り込んだ表示を共有でき、再読み込みしても残ります。

検索#

検索バーは、ほかのテレメトリエクスプローラーと同じ書き方に対応しています ( 検索構文 を参照)。

項目は、短い名前 (severity、class、category、activity、status、vendor、product、rule、user、host、ip、targetuser、targethost、targetip、processname、commandline、parentprocessname、observable、tactic、technique) か、 severityName や principalHost のような項目自体の名前です。それ以外の名前はソースの属性として読み取られます。 observable:<value> は、アクティビティのどちら側にあったかにかかわらず、その値に触れているすべてのイベントを見つけます。

ファセット#

サイドバーは、ウィンドウ内のイベントを ソース、 重大度、 イベントクラス、 カテゴリ、 アクティビティ、 ステータス、 ベンダー、 製品、 検出ルール、 送信元ユーザー、 送信元ホスト、 プロセス、 親プロセス ごとに数えます。値をクリックするとそのイベントだけを残し、横のマイナスをクリックすると除外します。もう一度クリックすると元に戻ります。グラフとすべての件数は、一覧にあるイベントをそのまま表します。

相関分析#

相関分析 は、ホスト、ユーザー、IP アドレスを中心にイベントを描きます。検索した値の周りにイベントクラスを最も高い重大度で示し、同じイベントに含まれるほかの値を外側の輪に配置します。クラスをクリックするとそのイベントの一覧、値をクリックするとその値で次の相関分析を行います。 イベント でイベントのパネルにある observable はどれも、その値で 相関分析 を開きます。

検出ルール#

検出ルールは Sigma ルールです。疑わしいアクティビティを記述するためのオープンな YAML 形式で、Status200 がスケジュールに沿ってあなたのイベントに対して実行します。一致すると ケース を開くか既存のケースに加わり、アラートを開き、必要に応じてインシデントを開き、Detection Finding をイベントに書き戻します。 Rule Library には、出発点として使える既製のルールがあります。

ルールを作成する#

10.x.x.x 以外からのログオン失敗に一致する最初のルール:

title: Failed logon burst
description: Repeated authentication failures from one source.
level: high
tags:
  - attack.t1110
  - attack.ta0006
detection:
  selection:
    className: Authentication
    statusName: Failure
  filter_internal:
    principalIp|startswith: '10.'
  condition: selection and not filter_internal

ルールで表現できること#

Status200 は Sigma のブール演算の中核部分を実行します。

• セレクションは、項目のマップ (すべての項目が一致する必要があり、値のリストはそのいずれかに一致) か、メッセージ内のどこかに一致するキーワードのリストです。
• 条件は、 and、 or、 not と括弧、または 1 of selection_*、 all of selection_*、 any of them、 all of them でセレクションを組み合わせます。
• 項目の修飾子: contains、 startswith、 endswith、 all、 re、 cased、 gt、 gte、 lt、 lte、 cidr、 exists、 windash。テキストは、 cased を付けない限り大文字と小文字を区別せずに比較されます。
• 項目は、型付きの項目 (principalUser)、その一般的な Sigma の綴り (CommandLine、src_ip、Hostname)、またはイベントにあるとおりに綴った任意の属性キー (threat.matched) です。
• Image と CommandLine はイベントの対象のプロセス、つまりプロセスの起動では起動したプロセス (processPath、processCommandLine) を読み、ParentImage と ParentCommandLine はそれを起動したプロセス (parentProcessPath、parentProcessCommandLine) を読みます。principalProcess は動作したプロセスで、起動では親プロセスにあたります。
• level は重大度を設定します。 informational、 low、 medium、 high、 critical のいずれかで、ない場合は medium です。 tags 内の ATT&CK ID (attack.t1110、attack.ta0006) は、検出結果の MITRE 項目に入ります。

| count() by principalIp > 5 のような集計は保存時に拒否されます。代わりに 相関ルール か、 グループ化のフィールド と 一致件数のしきい値 を使ってください。 logsource は情報としてのみ扱われ、何も絞り込みません。その絞り込みは className: Authentication のようにセレクションに入れてください。 timeframe は無視されます。ウィンドウはルールの間隔で決まるからです。

相関ルール#

Sigma の相関 は、一件ではなく複数のイベントの組み合わせで発火します。読み取るルールと一緒に、 --- で区切った YAML ドキュメントとして Sigma ルール（YAML） に貼り付けるか、プロジェクトにすでにあるルールを Sigma の name か id で指定します。 Rule Library には、サインインの失敗に成功が続くものなど、すぐに使えるルールがあります。

title: Failed sign-ins, then a success from the same address
level: high
correlation:
  type: temporal_ordered
  rules:
    - failed_sign_ins
    - successful_sign_in
  group-by:
    - principalIp
  timespan: 10m
---
title: Five failed sign-ins
name: failed_sign_ins
correlation:
  type: event_count
  rules:
    - failed_sign_in
  group-by:
    - principalIp
  timespan: 10m
  condition:
    gte: 5
---
title: Failed sign-in
name: failed_sign_in
detection:
  selection:
    className: Authentication
    statusName: Failure
  condition: selection
---
title: Successful sign-in
name: successful_sign_in
detection:
  selection:
    className: Authentication
    statusName: Success
  condition: selection

• グループは group-by のフィールドの値で、たとえばひとつのアドレスです。カウントはローリングです。2 回の実行に分かれたバーストも、その timespan 内では丸ごと数えられ、その長さは最大 24 時間です。
• new_value は Status200 独自の型です。Sigma には「初回確認」の相関がないためで、最大 30 日分の履歴と比べます。 value_sum 、 value_avg 、 value_percentile 、 value_median は保存時に拒否されます。
• 検出ルール の 種類 列に各ルールの種類が表示され、フォームにはルールが何を探すかが一文で示されます。

評価の設定#

グループ化とユニーク数は、ルールと同じ項目名を受け付けます。これらを使うと、しきい値は「同じものから、1 回の実行で、これだけの数」を意味し、上にモニターを重ねる必要はありません。

ルールが実行されるタイミング#

Status200 は毎分、前回の実行から間隔が経過した有効なルールを確認します。各実行は、イベントの時刻が前回の実行から 2 分前までにあるイベントを読み取り、次へ進みます。この 2 分は、書き込まれてから 1 分後に読み取られるログ行のように、まだ届く途中のイベントのための余裕です。

• ウィンドウは連続していて、スライドしません。間隔が 10 分なら、09:58 と 10:01 の失敗は別々の実行に入り、別々に数えられることがあるので、しきい値には余裕を持たせてください。
• ワーカーの停止やルールの再有効化などで間隔が空いた後は、次の実行が空白期間全体を、最大で直近 24 時間までカバーします。
• 実行がその時刻をすでに処理した後で 2 分以上遅れて届いたイベントは、保存され検索もできますが、そのルールが読み取ることはありません。
• しきい値に達したグループはすべて Detection Finding になり、1 回の実行で最大 10,000 件です。アラート、インシデント、ケースは件数の多い 100 個について開かれ、残りはルールについての 1 件のケースにまとめられます。ルールの 最終エラー に、一致したグループの数が表示されます。

重大度#

ルールの level は、その検出結果の重大度です。 informational、 low、 medium、 high、 critical は、それぞれ Informational、Low、Medium、High、Critical になります。アラートとインシデントには、プロジェクトの重大度のうちひとつが次の順で割り当てられます。

1. ルールの アラートの重大度 (または インシデントの重大度)。設定されている場合。
2. レベルと同じ名前を持つあなたの重大度。たとえば High。大文字と小文字は区別しません。
3. 順位による割り当て: critical と high のルールは最も重い重大度、それ以外は最も軽い重大度になります。

アラートと検出結果#

発火したグループはそれぞれ、 [Detection] <rule name> — <group value> というタイトル、グループ化のフィールドがないルールでは [Detection] <rule name> というタイトルのアラートを開きます。アラートが開いているあいだは、そのグループの新たな一致で別のアラートが開くことはありません。ルールに見えるのは一致だけで、攻撃が止まったことはわからないため、アラートは誰かが解決するまで開いたままです。

Detection Finding は、製品 Status200 Detections によるクラス Detection Finding (OCSF クラス 2004) のセキュリティイベントで、ルールの MITRE タグ、 observables の先頭にグループの値、そして次の属性を持ちます。

検出結果は通常のイベントです。 イベント で検索し、 相関分析 で掘り下げられます。新しいルールを静かに試すには、信頼できるようになるまで、検出結果以外のすべての動作をオフにしておきます。

セキュリティイベントのモニター#

セキュリティイベントのモニターは、フィルターに一致するイベントをローリングウィンドウで数え、その件数に通常のモニター条件を適用します。モニターのステータスを変え、アラートやインシデントを開き、オンコール担当者を呼び出します。 モニター → モニターを作成 で種類に セキュリティイベント を選んで作成します。 ほかのモニターと一緒にそこに一覧表示されます。

フォームには このテキストを含むイベントを監視、 セキュリティイベントを監視する期間、 イベントの重大度、 イベントクラス が表示されます。 テレメトリサービスでフィルター と 属性でフィルター は その他の項目 の中にあり、その見出しにはモニターが使っているものが表示されます。条件では Security Event Count を確認します。

検出そのものは、しきい値付きのルールとして書きます。ローリングウィンドウ、ひとりでに回復するステータス、ステータスページ、条件ごとに異なるオンコールポリシーが必要なときにモニターを使います。

検出を見張る#

検出結果はイベントなので、モニターでルール自体を見張れます。

• 嵐: クラス Detection Finding に対するモニターで、すべての検出結果を数えます。1 時間に 20 の異なるルールが発火するのは、単独のルールでは見えないシグナルです。
• 頻度の変化: ひとつのルールの status200.detection.rule_id で絞り込みます。週に一度発火するルールが 1 時間に 50 回発火しているなら、別の対応が必要です。
• 沈黙: いつもはいくつかある検出結果がゼロになったら、たいていはソースが送信をやめています。件数がある数を下回ったかを確認する条件を使ってください。

ルールの行にある モニターを作成 は、すでにこのように設定された新しいモニターを開きます。クラス Detection Finding、ルールの ID (名前を変えると変わってしまう名前は使いません)、そして直近 1 時間です。このようなモニターが数えるのは、その元のイベントではなく、実行ごと、グループごとにひとつの検出結果です。何かが発火する前に一定数のイベントを必要とするなら、ルールの 一致件数のしきい値 を使ってください。

脅威インテリジェンス#

脅威インテリジェンス は、既知の悪性 IP アドレス、ドメイン、URL、メールアドレス、ファイルハッシュの STIX/TAXII フィードを購読します。それらに触れているイベントには、届いた時点でルールやモニターが絞り込みに使える threat.* 属性が付き、毎分、最近のイベントがフィードと照合され、ルールと同じようにアラートと検出結果が開きます。 脅威インテリジェンス を参照してください。

保持と課金#

セキュリティイベントは、ほかのテレメトリと同じく取り込んだ GB 単位で課金され、テレメトリの保持期間のあいだ保持されます。保持期間は、 プロジェクト設定 → テレメトリと APM → データ保持 にあるプロジェクトの デフォルトの保持期間（日数） 、またはイベントが属するテレメトリサービスに設定した保持期間です。イベントの保持期間が終わると削除されます。

トラブルシューティング#

次のステップ#