OpenCTIにおけるIndicatorのDecayルール実装のご紹介

サイバー脅威インテリジェンスは使われるために存在します。有用であるためには、適切かつタイムリーである必要があります。これが、サイバーセキュリティにおいてIndicators of Compromise(IoC)のライフサイクル管理が非常に重要である理由です。しかし、IoCは数千単位で受信されることがよくあります。では、それらすべてを管理して、適切かつ時間的に敏感なコンテキストを維持するにはどうすればよいのでしょうか?

この問題に対処するため、OpenCTI 6.0にScore Decayアルゴリズムを導入し、IoCのライフサイクル管理をサポートします!

新しいDecayアルゴリズムによるIndicatorライフサイクルの変化

IoCは、そのパターンに一致するものすべてが「悪意がある」、または少なくとも脅威に関連していることを示します。この悪意性/関連性は、IoCの「スコア」と「valid_until」の値で表されます。6.0以前は、OpenCTIにおけるIndicatorのスコアは、新しい情報(手動更新、フィードからの新しいデータ、Playbook)に基づいてのみ変更でき、時間の経過では変更できませんでした。これは、時間の経過によるIoCの関連性の変化を表現できないOn/Offモデルでした。

Decayルールを有効にすると、Indicatorのスコアが時間の経過とともに減少するようになります。

Indicatorの概要では、スコアの横に「Lifecycle」という新しいボタンが表示されます。

ライフサイクルボタンを含むIndicatorスコア

Indicatorのライフサイクルビューを開くと、IoCライフサイクルを表す曲線が表示されます。テーブルには、監視されているすべての関連スコアがリストされ、それらに反応できるようになっています。これらのスコアの最後のものは、関連性がないためにIoCを無効化するスコアです。

Indicatorのライフサイクル詳細

曲線はコンテキストのために表示されますが、Indicatorの概要に表示され、データベースに保存されるIndicatorスコアは、テーブル内のスコア値を取ります。安定したスコアの時刻に達すると、プラットフォームはIoCのスコアを更新し、この更新は、UI上で手動でスコアが更新された場合と同じ方法で反応できます(ストリーム、Playbook、Notifierなど)。

OpenCTIプラットフォームはIndicatorのDecayルールをどのように選択しますか?

CTIプラットフォームには、デフォルトで複数のDecayルールが設定されており、Settings権限を持つユーザーは、この記事の管理セクションで説明されているように新しいルールを設定できます。

Decayルールの選択は、Indicatorの「メインobservableタイプ」と優先順位システムに基づいています。

新しいIndicatorが作成されると、Decayアルゴリズムは:

• Indicatorのメインobservableタイプに基づいてDecayルールを検索します(例:ドメイン名)
• 最も高い優先順位を持つDecayルールを選択します
• メインobservableタイプに該当するルールが存在しない場合、すべてのobservableタイプに一致する最も高い優先順位のDecayルールを採用します。

Decayルールは、Indicatorが作成されるときに選択されます。つまり、IndicatorがDecayルールで作成された後に、そのDecayルールのパラメータが変更されても、新しいパラメータはIndicatorに適用されません。ルールに一致する新しいIndicatorのみが新しいパラメータを持ちます。

また、OpenCTI 6.0に移行する前にプラットフォームに存在していたIndicatorには、Decayルールの遡及的な計算は行われません。Indicatorが「valid_until」日付に達すると、Indicatorは引き続き無効化されることに注意してください。Decayルールによるスコアの減少と無効化スコアは、無効化メカニズムと連携して機能します。

このIndicator Decayルールエンジンの設計は、パフォーマンス上の理由によるもので、OpenCTIプラットフォームには数百万の既存のIndicatorが存在する可能性があることを考慮しています。

UIまたはコネクタによってスコアが更新された場合はどうなりますか?

Indicatorの作成時のスコアから始まらないライフサイクル曲線を持つIndicatorが見られる場合があります。その理由は、UIで手動でスコアが更新されたり、コネクタ/フィードから更新された場合、この新しいスコアがDecay計算の開始スコアとして採用され、安定スコアの日付と無効化日付が再計算されるためです。Indicatorライフサイクル全体の理解を維持するために、この更新前にIndicatorが持っていた可能性のあるスコアは保持され、テーブルに表示されます。

スコア更新を含むライフサイクル詳細

たとえば、このスクリーンショットでは、Indicatorのスコアは2024年3月9日の作成時に79でしたが、何らかの理由で、2024年3月12日にユーザーによって96に更新されました。その結果、次の安定スコアと無効化スコアの日付が、2024年3月12日から再計算されました。

Decayアルゴリズムとルールの管理

管理者の場合、Decayルールは「Settings > Customization > Decay rules」で設定できます。

Decayルール管理

デフォルトで適用される4つの組み込みDecayルールを提供しています。

最も優先順位が低い最後のルールは、他のルールが一致しない場合に適用されるルールです。

組み込みルールは特別で、パラメータの変更、無効化、削除はできません。優先順位は0と1に設定されています。他のルールを適用したい場合は、独自のパラメータでルールを作成し、より高い優先順位(少なくとも2)を設定するだけです。

高速スコア減少を伴うDecayルールの例

低速スコア減少を伴うDecayルールの例

新しいルールを作成する際のパラメータは次のとおりです:

• メインobservableタイプ:作成時にこのリスト内のobservableタイプの1つを持つIndicatorがルールに一致します。空のリストは、ルールがすべてのIndicatorに一致することを意味します。
• ライフタイム(日数):曲線アルゴリズムに従ってスコアがゼロに達するまでにかかる日数です。
• Decay factor:このパラメータは、Decayアルゴリズム曲線の形状を定義します。0.33未満の値は、初期段階での緩やかな減少を示し、0.33を超える値は、より速い減少を示します。
• Reaction point:データベース内のIndicatorスコアの更新をトリガーし、反応できるようにするスコアです。
• Revoke score:Indicatorの無効化をトリガーするスコアです。Indicatorは、この無効化スコアに達したとき、またはvalid until日付に達したときのいずれか最初のイベントで無効化されます。
• Order:このパラメータは優先順位を表します。Indicatorのメインobservableが複数のルールに一致する場合、最も高い優先順位のルールが採用されます。同じ優先順位で2つのルールが一致する場合、そのうちの1つがランダムに選択されます。

Decay機能の次のステップ

将来的には、Decay機能をさらにアップグレードしたいと考えています!たとえば、IndicatorにSightingが追加されたときにスコアの変化を考慮するのは素晴らしいアイデアかもしれません。また、Markingなどの他のプロパティに基づいて、より詳細なフィルタを定義できると素晴らしいでしょう。

ぜひ、Community Slackチャンネルでご意見をお聞かせください!

参考ドキュメント:
使用方法: https://docs.opencti.io/latest/usage/indicators-lifecycle
管理: https://docs.opencti.io/latest/administration/decay-rules/
マネージャー設定: https://docs.opencti.io/latest/deployment/configuration/#engines-schedules-and-managers