はじめのProfessional Security Operations Engineer 認定取得講座⑭MISP連携とIOCマッピング、Sensitive Data Protection連携、YARA-L 2.0パフォーマンスチューニングを説明します！

Google Security Operations（Google SecOps）で脅威検知を行う上で、YARA-L 2.0による検出ルールを適切に設計することは、効率的なSOC運用につながります。特に、単一のイベントだけで判定できる検知と、複数イベントを時間軸で相関させる検知では、ルールの構造が異なります。

本記事では、シングルイベントルールとマルチイベントルールの違いを整理し、match セクションを使用するべきケースと、不要な場合にシングルイベントルールへリファクタリングする方法を解説します。さらに、outcome セクションによる検知結果へのコンテキスト付与や、ルール数の制約を考慮した設計についても紹介します。

Professional Security Operations Engineer（PSOE）認定試験の対策として、YARA-L 2.0のルール構造とパフォーマンスを意識した検出ルール設計を理解しておきましょう。

是非、最後までご覧いただけると嬉しいです。

MISP連携とIOCマッピング

オープンソースの脅威インテリジェンスプラットフォームである MISP（Malware Information Sharing Platform） は、世界中のSOCやCSIRTでIOC（侵害指標：IP、ドメイン、URL、ファイルハッシュなど）を共有・管理するために広く利用されています。

Google Security Operationsにおいて、MISPに蓄積された最新の脅威インテリジェンスをリアルタイム検出や相関分析に活用するためには、Bindplane（OpenTelemetry Collector）をベースとした自動収集パイプライン と、UDM（統合データモデル）エンティティへのCBN（Code-Based Normalization）マッピング を正しく設計する必要があります。

本記事では、Professional Security Operations Engineer認定試験対策および実用的なThreat Intelligence設計に不可欠な、MISPとGoogle SecOpsの統合パイプライン構築手法を解説します。

1. MISP連携パイプラインの全体像と設計目的

MISPに保存されたIOCデータ（IP、ドメイン、ファイルハッシュ等）をGoogle SecOpsへ連携する主な目的は、「最新の脅威インジケーターと、組織のセキュリティイベントログ（UDM Event）を自動相関（Context Graph / Threat Match）させること」 にあります。

パイプライン構成要素

1. MISP REST API / Exporter：MISPのイベント・属性データ（Attributes）を特定間隔でエクスポート。
2. Bindplane Agent (OpenTelemetry)：MISPのAPIエンドポイント（またはエクスポートファイル）を定期ポーリング（HTTP Receiver等）し、データ整形を適用。
3. Google SecOps Ingestion Layer：取得したJSON/CSVデータをGoogle SecOpsへ暗号化送信。
4. CBN Parser (Parser/Extension)：取り込まれたMISP属性データをUDMの ENTITY_THREAT_INTELLIGENCE や entity.metadata.threat 構造にマッピング。

2. BindplaneによるIOCデータ収集設計

Bindplaneエージェントを使用することで、MISPサーバーからのデータ取得と前処理を安全かつ一元的に管理できます。

収集方式の選定

• HTTP Receiver（REST APIポーリング）：MISPの /attributes/restSearch エンドポイントに対し、APIキーを用いて定期的にリクエスト（例: 過去1時間以内に更新されたIOCを取得）を送信します。
• 前処理プロセッサ（Bindplane Processors）:
  • 不要データのドロップ：無効化されたIOC（deleted: true）や信頼度の低いタグを持つデータを除外。
  • 機密情報の除外：MISP内部のプライベートノートや担当者連絡先情報を送信前に削除。

3. UDMへの正規化マッピング仕様（CBN）

MISPから取得したIOCログは、Google SecOps内部で単なる「ログイベント」ではなく、アセットや通信に付与される「脅威コンテキストエンティティ（Entity）」 として正規化マッピングされる必要があります。

主要フィールドのマッピング定義

CBN（Code-Based Normalization）の記述例

filter {
  mutate {
    replace => {
      "entity.metadata.entity_type"                        => ""
      "entity.metadata.vendor_name"                        => ""
      "entity.metadata.product_name"                       => ""
      "entity.metadata.product_entity_id"                  => ""
      "entity.metadata.threat[0].category_details[0]"      => ""
      "entity.metadata.threat[0].description"              => ""
    }
  }

  json {
    source   => "message"
    target   => "misp"
    on_error => "json_parse_error"
  }

  if ![json_parse_error] {
    mutate {
      replace => {
        "entity.metadata.entity_type"       => "IP_ADDRESS"
        "entity.metadata.vendor_name"       => "MISP"
        "entity.metadata.product_name"      => "MISP Threat Sharing"

        "entity.metadata.product_entity_id" => "%{[misp][uuid]}"
      }
      on_error => "mutate_metadata_error"
    }

    if [misp][type] == "ip-dst" or [misp][type] == "ip-src" {
      mutate {
        replace => {
          "entity.ip[0]"                                => "%{[misp][value]}"

          "entity.metadata.threat[0].category_details[0]" => "%{[misp][category]}"
          "entity.metadata.threat[0].description"         => "%{[misp][comment]}"
        }
        on_error => "mutate_ip_error"
      }
    }
  }
}

4. YARA-L 2.0での自動マッチングと検知設計

UDMエンティティとして正規化されたMISP IOCデータは、YARA-L 2.0検出ルールから参照（グラフ結合）することが可能です。

ルール記述パターン（イベントとMISP Threat Graphの相関）

rule misp_ioc_ip_match {
  meta:
    author      = "SOC Engineer"
    description = "MISP Threat Intelligence IOCと一致する不審なネットワーク通信を検知"
    severity    = "High"

  events:
    // 1. 組織内のネットワーク通信ログ
    $net.metadata.event_type = "NETWORK_CONNECTION"

    // ip-dst（通信先が悪意あるIP）を検知するには target.ip を使用
    // ip-src（送信元が悪意あるIP）を検知するには principal.ip を使用
    // 両方を検知したい場合はルールを分けるか、OR条件で記述する
    $net.target.ip = $ip

    // 2. MISPから取り込まれた脅威インテリジェンスエンティティ
    $misp.graph.metadata.entity_type = "IP_ADDRESS"
    $misp.graph.entity.ip = $ip
    $misp.graph.metadata.vendor_name = "MISP"

  match:
    $ip over 5m

  outcome:
    $threat_description = array_distinct($misp.graph.metadata.threat.description)
    $misp_category      = array_distinct($misp.graph.metadata.threat.category_details)
    $risk_score         = 85

  condition:
    $net and $misp
}

5. 実運用におけるパフォーマンスとメンテナンスの考慮点

1. IOCの有効期限（TTL）と陳腐化防止：古いIOC（特にIPアドレス）は偽陽性（False Positive）の原因になります。MISP側で評価期限を設定するか、Google SecOpsにエクスポートする際に timestamp の範囲を「過去30日間に更新された活性化IOCのみ」に絞り込むフィルタリング設計が必須です。
2. 取り込みバッファと速度制御（Throttling）：MISPの初回全量エクスポート時には数万件のIOCが一括送信されるため、取り込みレート制限（Ingestion Rate Limit）に接触しないよう、Bindplaneプロセッサでのバッチサイズ調整（batch processor）を適用します。

MISP連携とIOCマッピングのまとめ

MISPとGoogle SecOpsを連携することで、MISPで管理しているIPアドレス、ドメイン、URL、ファイルハッシュなどのIOCをGoogle SecOpsの検出や相関分析に活用できます。Bindplaneを利用してMISPからIOCを収集し、CBNによってGoogle SecOpsのUDMへ適切に正規化することが、連携設計の重要なポイントです。

さらに、正規化した脅威インテリジェンスをイベントと関連付けることで、IOCとの一致を検出ルールや脅威調査に活用できます。実運用では、古いIOCによる誤検知を防ぐための有効期限管理や、大量のIOCを取り込む際の速度制御も重要になります。

PSOE試験対策として、MISPからGoogle SecOpsへのIOC連携、Bindplaneによる収集、UDMへのマッピングという一連の流れを理解しておきましょう。

Sensitive Data Protection連携

セキュリティ運用（SecOps）において、アセット上で「どのような操作が行われたか（ログ）」を監視するだけでなく、「そのアセットにどのような重要データが保管されているか（コンテキスト）」を把握することは、アラートの優先順位付けやインシデントの影響度評価において決定的な差を生みます。

Google Cloud の Sensitive Data Protection（SDP / 旧 Cloud DLP） は、Cloud Storage、BigQuery、Datastream 等に存在する機密データ（クレジットカード番号、マイナンバー、個人識別情報（PII）、秘密鍵など）を自動的に発見・分類・プロファイリングします。本記事では、SDP が生成したアセットの機密性メタデータを Google Security Operations（Google SecOps） に取り込み、高度な脅威検知やリスクスコアリングに応用する実践手法を、Professional Security Operations Engineer（PSOE）認定試験の観点を交えて解説します。

1. なぜ SOC に Sensitive Data Protection（SDP）の連携が必要なのか

従来の SIEM 運用における大きな課題の一つが、「アラート過多（Alert Fatigue）」 と 「コンテキストの欠如」 です。

たとえば、「あるサービスアカウントが Cloud Storage バケットから大量のオブジェクトをダウンロードした」というイベントが発生した場合。

• 情報なし：単なるバッチ処理の可能性も高く、緊急度の判定が困難。
• SDP 連携あり：当該バケットに CREDIT_CARD_NUMBER や SECRET_KEY が含まれ、データリスクレベルが CRITICAL であることが分かっていれば、即座に「重大なデータ引き出し（Data Exfiltration）の疑い」として最優先で対応可能。

SDP のメタデータを Google SecOps に統合することで、SOC アナリストは「データ自体の機密性」に基づいたデータ中心のセキュリティ運用（Data-Centric SecOps） を実現できます。

2. SDP アセットメタデータの取り込みと UDM エンティティマッピング

SDP がスキャンおよびプロファイリングしたデータ分類結果（Discovery Profiles / Inspection Results）は、Google Cloud の Pub/Sub、Cloud Storage、または Security Command Center（SCC）を経由して Google SecOps にエクスポート・取り込みを行います。

UDM エンティティ（ENTITY_RESOURCE）へのマッピング構造

取り込まれた SDP メタデータは、単一のイベントログではなく、アセットの属性を示す エンティティデータ（ENTITY_RESOURCE） として UDM に格納されます。

• アセット識別子（Entity Key）：resource.name（例: //storage.googleapis.com/company-confidential-bucket）
• データ分類情報（InfoTypes）：attribute.labels または additional.fields
  • info_type: CREDIT_CARD_NUMBER, JAPAN_INDIVIDUAL_NUMBER, API_KEY
  • data_risk_level: HIGH, CRITICAL
  • sensitivity_score: 90

Google SecOps のエンティティグラフ（Entity Graph）エンジンは、このアセット情報と日々のアクセスイベント（STORAGE_OBJECT_GET や BIGQUERY_QUERY など）をリソース名（target.resource.name）で自動的に紐付け（相関付け）ます。

3. YARA-L 2.0 によるデータ意識型（Data-Aware）脅威検知とリスクスコアリング

SDP のコンテキストを UDM エンティティとして保持することで、YARA-L 2.0 ルール内で「イベントデータ」と「SDP エンティティ属性」を比較評価できるようになります。

YARA-L 2.0 ルール記述例：機密データアセットからの異常ダウンロード検知

rule sdp_sensitive_data_exfiltration_alert {
  meta:
    author      = "SOC Detection Engineering Team"
    description = "Sensitive Data ProtectionでHIGH/CRITICALと判定されたアセットに対する不審な大量ダウンロードを検知"
    severity    = "Critical"

  events:
    // 1. Cloud Storageからのデータ取得イベント
    $event.metadata.event_type  = "USER_RESOURCE_ACCESS"
    $event.metadata.product_name = "Google Cloud Storage"
    $event.target.resource.name  = $resource_name

    // 2. SDPのアセットエンティティメタデータとの結合
    $entity.graph.entity.resource.name = $resource_name
    $entity.graph.entity.resource.attribute.labels["data_risk_level"] = $risk_level

    // リスクレベルが HIGH または CRITICAL のアセットを対象
    $risk_level = "HIGH" or $risk_level = "CRITICAL"

  match:
    $resource_name over 5m

  outcome:
    $risk_score = max(
      if($risk_level = "CRITICAL", 100,
      if($risk_level = "HIGH", 80, 50))
    )
    $principal_user = array_distinct($event.principal.user.userid)
    $info_types     = array_distinct($entity.graph.entity.resource.attribute.labels["info_type"])

    $total_bytes    = sum($event.network.sent_bytes)

  condition:
    // 頻度のみの検知から → 「頻度が高い かつ 転送量が大きい」に強化
    #event > 100 and $total_bytes > 104857600  // 転送量100MB以上
}

ポイント：Outcome Conditionals による動的スコアリング

上記のように outcome セクションで条件分岐（if-then-else）を用いることで、アクセス対象のデータの機密性レベルに応じて動的にアラートのリスクスコア（100, 80等）や緊急度を変更できます。これにより、一般的なアセットへのアクセスによる誤検知ノイズを抑えつつ、真に危険なデータ漏洩の兆候のみをエスカレーションできます。

4. SOAR ハンドブック自動化と Zero Trust（NIST SP 800-207）への応用

SDP メタデータと結びついたアラートが生成された後、Google SecOps SOAR のハンドブック（Playbook）をトリガーして迅速な自動対応を実施します。

1. ケースの緊急度自動昇格：SDP で機密データが確認されているアセットに関するアラートは、SOAR 上で優先度「Critical」のケースとして即座に担当アナリストへ割り当て。
2. アイデンティティとアクセスの隔離（Isolation）：不審な操作を行ったユーザー/サービスアカウントの IAM 権限の一時的剥奪や、セッションの強制無効化。
3. VPC Service Controls（VPC-SC）による動的境界強化：リスクが検出されたアセットが含まれるプロジェクトに対し、アクセス許可ゾーンを限定。

NIST SP 800-207 ゼロトラスト・アーキテクチャとの整合

NIST SP 800-207 では、「アクセス許可およびポリシー決定（Policy Decision Point）は、対象データの感度（Data Sensitivity）やリソースの保護要件に基づいて動的に評価されるべき」と規定されています。SDP と Google SecOps の連携は、まさにデータ感度の可視化とセキュリティポリシーの動的適用を体現する構成です。

Sensitive Data Protection連携のまとめ

Professional Security Operations Engineer 試験において、本トピックに関する要点は以下の通りです。

• イベントデータ vs エンティティデータ：ログ（操作履歴）と SDP（アセットの機密性属性）の違いを理解し、エイリアシングやリソース名による結合ロジックを評価できること。
• YARA-L 2.0 の Outcome 条件分岐：SDP の info_type や data_risk_level を用いて、動的なリスクスコア算定（$risk_score）ルールを設計できること。
• データ中心のアラート優先順位付け：クラウド環境におけるデータ漏洩リスクを削減するため、SDP と SOAR ハンドブックを連動させたプロアクティブな応答設計を構築できること。

SDP アセットメタデータを Google SecOps に統合することで、量的なログ監視から「質（データの価値）」に着目した高度な SOC 運用へと進化させましょう。

YARA-L 2.0パフォーマンスチューニング

Google Security Operations（Google SecOps）の検出エンジンにおいて、検出ルールの処理速度やシステムリソースの効率化（レイテンシ削減）は、大規模なエンタープライズ環境でリアルタイム脅威検知を実現するための要となります。

特に、時間相関や複数イベントのマッチングを必要としない単純な検知ルールにおいて、不必要に match セクション（マルチイベントルール）を使用している場合、無駄なインメモリバッファと時間ウィンドウ（Hop/Sliding Window）のオーバーヘッドが発生します。本記事では、Professional Security Operations Engineer（PSOE）認定試験および実践的な検出エンジニアリングに直結する、シングルイベントルールとマルチイベントルールの内部処理構造の違いと、リファクタリングによるパフォーマンス向上の具体手法を解説します。

1. YARA-L 2.0における2つのルール評価メカニズム

Google SecOpsの検出エンジン（Detect Engine）は、取り込まれたUDM（統合データモデル）イベントを評価する際、ルールの構造に応じて2種類の評価メカニズムを使い分けています。

① シングルイベントルール（Single Event Rule）

• 構造：match セクションが存在しないルール。
• 評価タイミング：ログがGoogle SecOpsのストリーミングパイプラインに取り込まれた直後に、インメモリで即時単体評価されます。
• 特徴：ステートレスに近い即時処理を行うため、メモリ保持や時間バッファを必要とせず、マイクロ秒〜ミリ秒レベルの超極小レイテンシでアラートを生成します。

② マルチイベントルール（Multiple Event Rule）

• 構造：match セクションを含み、監視時間枠（over 5m など）が定義されたルール。
• 評価タイミング：指定された時間ウィンドウ内において、プレースホルダ変数（例: $user や $ip）に基づいて複数のイベントをメモリ上にバッファ・保持し、相関分析やカウント集計を実行します。
• 特徴：高度な攻撃シナリオ（ブルートフォースや横移動）の検知に不可欠ですが、イベントを保持・保持状態をトラッキングするためのコンテキストバッファとCPUリソースを消費します。

2. レイテンシとリソースオーバーヘッドの徹底比較

相関分析を必要としないルールに match セクションを適用してしまうと、システム全体で大きなパフォーマンス劣化を招きます。両者の仕様と動作の違いは以下の通りです。

3. 実践リファクタリング：アンチパターンと最適化

アンチパターン（不必要なマルチイベントルールの指定）

以下は、コマンドラインで特定の不審なPowerShell引数が実行されたことを検知したいルールですが、誤って match セクションが記述されているアンチパターンです。

rule suspicious_powershell_execution_antipattern {
  meta:
    author      = "SOC Engineer"
    description = "不審なPowerShell引数の検知（アンチパターン）"
    severity    = "High"

  events:
    $e.metadata.event_type         = "PROCESS_LAUNCH"
    $e.target.process.command_line = /powershell.*-ExecutionPolicy Bypass/i
    // matchセクションで使うために$userプレースホルダーを定義している
    $e.principal.user.userid       = $user

  //    matchセクションを記述しているアンチパターン
  match:
    $user over 1m

  outcome:
    // matchセクションがあるため、イベント変数にはarray_distinctが必要になる
    $principal_user = array_distinct($e.principal.user.userid)
    $command_line   = array_distinct($e.target.process.command_line)
    $hostname       = array_distinct($e.principal.hostname)
    $risk_score     = 85

  condition:
    $e
}

このルールは単一の PROCESS_LAUNCH イベントで判定が自己完結しているにもかかわらず、$user ごとに1分間の状態バッファをメモリ上に作成するため、検出エンジンに不要な計算負荷を与え、アラート発生の遅延を引き起こします。

リファクタリング後（シングルイベントルールへの最適化）

match セクションを完全に削除し、シングルイベントルールとしてリファクタリングします。

rule suspicious_powershell_execution_optimized {
  meta:
    author      = "SOC Engineer"
    description = "シングルイベントに最適化されたPowerShell実行検知"
    severity    = "High"

  events:
    $e.metadata.event_type         = "PROCESS_LAUNCH"
    $e.target.process.command_line = /powershell.*-ExecutionPolicy Bypass/i

  outcome:
    $principal_user = $e.principal.user.userid
    $command_line   = $e.target.process.command_line
    $target_process = $e.target.process.file.full_path
    $hostname       = $e.principal.hostname
    $risk_score     = 85

  condition:
    $e
}

4. パフォーマンスチューニングの判断フローとベストプラクティス

1. 時間条件・集計の必要性をチェック
   • 「5分間に10回失敗」や「A発生後にBが発生」といった時間的・複数的条件がない場合、即座に match セクションを排除してシングルイベント化を検討します。
2. Outcomeセクションによる動的情報の出力
   • match セクションを削除しても、アラートの分析に必要なユーザーID、ホスト名、IPアドレスなどは outcome セクションで指定することで何ら不足なくコンテキストを付与できます。
3. パッケージ上限（Package Caps）の回避
   • Google SecOpsのライセンス階層（Standardパッケージ等）では、マルチイベントルールの同時実行数（75ルール制限等）が厳しく制限されています。無駄なマルチイベントルールをシングルイベント化（上限1,000ルール）することで、貴重なマルチイベントルールの枠を確保できます。

YARA-L 2.0パフォーマンスチューニングのまとめ

YARA-L 2.0では、単一イベントで判定できる検知と、複数イベントの時間的な相関を必要とする検知を適切に使い分けることが重要です。match セクションは複数イベントの相関分析に有効ですが、不要な場合に使用すると、時間ウィンドウやイベント保持などのオーバーヘッドにつながります。

単一イベントで完結する検知は、match セクションを使用せず、シングルイベントルールとして設計することで、より効率的なルール構成を検討できます。また、outcome セクションを活用することで、検知結果にユーザーやプロセスなどのコンテキストを付加できます。

PSOE試験対策として、シングルイベントルールとマルチイベントルールの違いと、match セクションを使用するべき条件を理解しておきましょう。

まとめ

今回は、下記３点について説明しました。

1. MISP連携とIOCマッピング
2. Sensitive Data Protection連携
3. YARA-L 2.0パフォーマンスチューニング

YARA-L 2.0では、単一イベントで検知できるケースと、複数イベントの時間的な相関が必要なケースを適切に使い分けることが重要です。match セクションは複数イベントの相関や時間条件を定義するために有効ですが、単一イベントで判定できるルールに不要に使用する必要はありません。時間的な相関を必要としないルールは、match セクションを使用しないシングルイベントルールとして設計することで、効率的なルール構成を検討できます。

また、outcome セクションを活用することで、ユーザーやプロセスなどの情報を検知結果に付加し、アラートの調査に必要なコンテキストを提供できます。

PSOE試験対策として、シングルイベントとマルチイベントの違い、match を使用する条件、outcome の役割を整理して理解しておきましょう。

これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！

それでは、次回のブログ！