How to design a real-time security baseline engine in the field of information security

1. セキュリティ分析とは

過去 10 年間で、ビッグデータ技術は急速に発展してきました。
セキュリティ分析のシナリオや手法も進化を続けています。
現在、一般的に使用されているセキュリティ分析のプロセスは、大きく 3 つの段階に分けられます。


* ログ収集と分析。
サーバー、ゲートウェイデバイス、端末、データベース、その他のデータソースから、トラフィックログ、脅威ログ、操作ログ、端末ログなどのデータをさまざまな方法で収集します。


* リアルタイムセキュリティ分析。
分析プロセスには主に、セキュリティベースライン、相関分析、セキュリティルール、脅威インテリジェンス、セキュリティナレッジベースが含まれます。


* セキュリティ運用と状況認識。
セキュリティ分析の結果に基づき、状況の可視化、セキュリティ運用、複数デバイスのセキュリティ連携、セキュリティオーケストレーションなどの機能を実装します。


前述の図に示すように、セキュリティ分野には主に 3 つの特徴があります。


* 迅速な対応。
セキュリティインシデントは、脆弱性の公開やウイルスの流行など、突発的に発生することが多く、短時間で急激に進行します。
そのため、突発的なセキュリティインシデントに迅速かつ効果的・実用的に対応し、お客様のニーズに即応して、さまざまなセキュリティインシデントに第一时间で対応できる必要があります。


* シーンのカスタマイズ。
セキュリティ分析は従来のビッグデータ分析シナリオとは若干異なり、正常ではなく異常を検知するもので、分野ごとに独自の要件があります。
そのため、多くの分野でカスタム開発の必要性が生じます。


* 限られたリソース。
従来のインターネットビッグデータプラットフォームの利用と比較すると、セキュリティ分析に利用できるリソースには多くの制約があります。
通常、ユーザーは予算とリソースの制約を受け、利用可能なコンピューティングリソースとストレージリソースの規模を可能な限り圧縮・最適化しようとします。
これにより、多数のコンポーネントが混在デプロイされ、将来のハードウェアやクラスター拡張のコストも高く、プロセスも非常に長くなります。


リアルタイムのデータセキュリティにおいては、5 つの要件があります。


* 1 つ目は、リアルタイム分析の必要性です。
セキュリティ検出にはレイテンシに対する厳しい要件があり、攻撃側と防御側の間には時間的な乖離があるため、異常を第一时间に検知できる必要があります。
同時に、セキュリティイベント駆動型であるため、ソリューションを迅速に起動し、タイムリーに対応し、最短時間で保護機能を構築できる必要があります。


* 2 つ目は、非常に豊富な分析セマンティクスを提供する必要性です。
セキュリティ検出シナリオは通常複雑であり、ほとんどのセキュリティ分析シナリオをカバーするために、豊富なセキュリティ分析セマンティクスを提供する必要があります。


* 3 つ目は、柔軟なデプロイです。
お客様の環境は非常に複雑であるため、お客様が自社構築したビッグデータプラットフォームや、購入されたいくつかのクラウドプラットフォームなど、さまざまなビッグデータプラットフォームをサポートする必要があり、大きなバージョン互換性も備えている必要があります。


* 4 つ目は、最小限のリソース使用量を実現する必要性です。
1 ノードから数十、数百ノードのクラスターまでのデプロイをサポートし、大規模でありながら可能な限り少ないリソースで稼働します。
たとえば、数千の分析ルールやセキュリティベースラインを同時に実行できます。


最後は、安定した運用です。
セキュリティプロダクトはクライアント側にデプロイされ、7×24 時間 1 日中稼働する必要があります。
極めて高い運用安定性を提供し、手動でのメンテナンスや介入を最小限に抑え、お客様に意識させないレベルが求められます。


従来のセキュリティ分析手法は、一般的に事前知識に基づき、特徴量ベースの検出技術を用いて異常検知を行います。
検出対象のデータやログの特徴を分析し、検出可能な特徴を手動で要約・集計してセキュリティモデルを構築します。
たとえば、セキュリティルールや脅威インテリジェンスなどです。
この手法は比較的シンプルで信頼性が高く、既存の攻撃手法には効果的に対処できますが、対応する検出特徴を持たない未知の攻撃手法を効果的に検出することはできません。


セキュリティベースラインは、動作ベースの検出手法を採用し、検出対象のデータやログを使用して、さまざまな方法で動作特徴を学習し、セキュリティベースラインを構築して、異常検知に活用します。


セキュリティベースラインのユースケースをよりよく理解していただくために、3 つの実際のシナリオをご紹介します。


シナリオ 1: DBA ユーザーアカウントのログインが異常です。
たとえば、ログイン場所の異常、ログイン時間の異常、データベース使用行動の異常などです。
例えば、DBA ユーザーが通常特定の時刻、特定の IP または特定の場所からログインするのに、ある日突然別の場所からログインし、しかもそれが通常のログイン時間でなかった場合、これは異常である可能性があり、異常イベントを生成する必要があります。


シナリオ 2: メールで送信された添付ファイルの数が正常値を超えています。
たとえば、セキュリティベースライン学習部門や会社全体が送信したメールの行動データを分析した結果、特定のユーザーが送信した添付ファイルの数が過去の学習データとかなり異なる場合、これは異常の可能性があります。


シナリオ 3: VPN サービスへの最近のアカウントログイン数が異常です。
ユーザーアカウントの VPN 過去のログイン行動を学習してセキュリティベースラインを構築し、将来異常なアカウントログインが見つかった場合に、異常イベントを生成します。


2. コンピューティングフレームワークの選択

現在、Spark と Flink という 2 つの主流なリアルタイムコンピューティングフレームワークがあります。
私たちがこのエンジンの設計を始めたのは 2018 年頃で、当時は Storm、Spark、Flink の 3 つのコンピューティングフレームワークを調査しました。
さまざまな要素を考慮した結果、最終的に Flink を基盤コンピューティングフレームワークとして選択しました。
当時の Flink はバージョン 1.4 前後で、比較的成熟したバージョンでした。
他のフレームワークと比較して、API とその基盤となる分散・ストリームコンピューティングの実装方法が、私たちのユースケースにより適合していました。


Flink の利点はより際立っています。
柔軟なデプロイが可能な分散コンピューティングフレームワークであり、現在一般的なビッグデータプラットフォームに適応できます。
優れた処理性能を備え、高スループットと低レイテンシを実現でき、リアルタイムセキュリティ分析に非常に適しています。
また、柔軟な DataStreaming API を提供し、カスタム要件の実現を容易にします。
さらに、使いやすいチェックポイントとセーブポイントのメカニズムがサポートされています。
しかも、現在非常に人気のあるコンピューティングフレームワークとして、コミュニティが活発で、豊富なドキュメントとシナリオサンプルがあります。


Flink には多くの利点がありますが、企業のリソースが限られており、ルールセットの数が数千規模である場合、Flink はビジネス要件とパフォーマンス要件を満たす上で多くの問題に直面しています。
たとえば、大規模なルールセマンティクス/フロー最適化がない、セキュリティシナリオ向けのカスタムウィンドウやロジックがない、セキュリティベースラインに関連するオペレータがない、リソース保護メカニズムがないなどです。


3. エンジン設計

エンジンのアプリケーションフレームワークは 3 層に分かれています。


* 最下層はデプロイ層で、通常はビッグデータクラスターです。


* 2 層目はセキュリティ分析層で、Flink DataStreaming API に基づいてセキュリティベースラインエンジンを構築します。
Flink が基盤となる分散コンピューティングとイベントストリーム送信を担当し、具体的なビジネス計算はセキュリティベースラインエンジンで完了します。
セキュリティベースラインエンジンからユーザーへのインターフェースはルールと DSL です。
ユーザーはルール DSL をインターフェースを通じてエンジンに送信します。
エンジンはルールと DSL に従ってイベントフローを分析・計算し、ルールのセマンティクスに従って外部データを使用します。
たとえば、ナレッジデータ、脅威インテリジェンス、資産と脆弱性などです。


* ユーザーは 3 層目のアプリケーション層を通じてエンジンを管理・使用します。
そして、エンジンのデータ結果に基づく状況分析、セキュリティ運用、リソース監視などの具体的なセキュリティサービスを提供します。


エンジンのビジネスプロセスは、ユーザーインターフェース、エンジンサービス、エンジン分析タスクの 3 つの部分に分かれています。
ユーザーはユーザーインターフェースを通じて、ルールの設定、ベースライン管理、運用監視を行います。
エンジンサービスは、RESTful API の形式で、ルールの配信、ベースラインの配信、状態監視などのサービスをユーザーに提供します。
エンジンサービスはユーザーのルール配信リクエストを受信した後、配信されたルールセットの分析と最適化を行い、分析タスクコードパッケージを生成する必要があります。
分析タスクコードはビッグデータクラスターに送信されて実行され、分析タスクは実行中にエンジンサービスのベースラインデータを受信し、ランタイムベースラインの追加、削除、変更を行います。
また、分析タスクはタスクの実行状態をエンジンサービスに報告し、エンジンサービスはタスクの実行状態をビジネスモニタリング情報に変換し、ユーザーのクエリと分析に提供します。


ほとんどのユーザーは研究開発人員ではないため、セキュリティ分析シナリオ向けに特別に最適化されたセキュリティ分析言語を提供する必要があります。
以下の要件を備えている必要があります。


* 使いやすく、学習コストが低く、研究開発の背景がない人でも簡単な学習後に使用でき、セキュリティアナリストの直感的な思考に適合していること。

* 豊富なデータ型を提供すること。
まず、豊富な基本データ型を提供し、次に、セキュリティ分析で一般的に使用される IP、各種時間、資産、脆弱性、脅威インテリジェンス、地理位置など、ユーザーがカスタマイズせずに直接さまざまなデータを使用できること。

* 豊富なセマンティクスを提供すること。
特に、セキュリティ分析セマンティクスの拡張とカスタマイズ。

* 拡張をサポートすること。
提供するセキュリティ分析セマンティクスは比較的包括的で、ほとんどのセキュリティ分析シナリオをサポートしていますが、直接サポートできない特殊なシナリオも存在します。
その場合、拡張方法でそのような要件をサポートする必要があります。


セキュリティ分析言語には、セキュリティアナリストが設計したセキュリティ分析文とルールをコンパイル・最適化するための専用コンパイラを設計する必要があります。
コンパイラは、いくつかの機能と最適化のサポートを提供する必要があります。


* 共通表現の最適化。
分析文内の同じセマンティックロジックを最適化し、繰り返しの計算と計算量を削減します。

* 参照データテーブルの最適化。
ルールセットには数千の分析文とルールが含まれる可能性があり、大量の外部データテーブルデータを参照します。
テーブル計算に対する計算最適化が必要です。
たとえば、ハッシュマッチング、大規模 IP マッチング最適化、大規模正規表現マッチングと文字列マッチングの最適化などです。

* 定数表現の最適化。
演算パフォーマンスを向上させます。

* テーブル参照の最適化。
参照例のマージと参照セマンティクスのマージの 2 つの部分を含み、参照テーブルのリソース消費を削減します。


分析文とルールがコンパイルされた後、実行サブグラフが生成されます。
各文とルールは 1 つのサブグラフに対応します。
この時点で、すべてのルールを集めてグラフ最適化を行う必要があり、これは 4 つのプロセスに分けられます。


第 1 歩はグラフ融合です。
グラフ融合はサブグラフの融合を含み、ルールセット内のすべてのサブグラフを 1 つの実行グラフに融合し、その後グラフノードのセマンティック融合、タイムウィンドウのマージ、共通リソースの参照最適化を行います。


第 2 歩はデータフローの最適化で、グラフの規模を縮小し、送信データ量を削減します。
主に、キーの前置、セマンティック等価ノードの融合、ネットワークスループットのバランス、データスキューの削減、ノードのマージ、超巨大グラフのノード数の大規模圧縮などの操作を行います。


第 3 歩はフィールドクリッピングで、送信イベントのサイズを削減することでネットワーク IO 負荷を軽減します。
主に、グラフ上のフィールド派生とクリッピング、フィールドのマージを含みます。


最後はコード生成で、文とルールのセマンティクスを分析してコードを生成し、実行グラフを Flink DataStream API にマッピングします。


リアルタイムコンピューティングのコア要素の 1 つは時間であり、異なる時間処理方法と実装スキームは、非常に異なる、あるいは完全に異なる計算結果をもたらします。
リアルタイム分析では、時間は主にタイムウィンドウとタイムラインの 2 つの機能に影響します。


セキュリティ分析シナリオでは、タイムウィンドウは一般的なスライディングタイムウィンドウをサポートするだけでなく、毎年、毎月、毎週などの自然時間のスライディングタイムウィンドウもサポートする必要があります。
自然に、あるいはさらに長い期間では、カスケードウィンドウの繰り返しデータ融合をサポートして、データストレージ量を削減し、繰り返し計算を自動的に排除し、繰り返しアラームを回避し、タイムタイマーをマージし、順序不同のイベントを正しく処理し、イベントの順序不同による誤計算を回避する必要があります。


タイムラインは、イベント発生時間と時間処理の 2 つのカテゴリに分類でき、その後、時間精度を拡張します。
異なる時間精度は、処理パフォーマンスとストレージに大きな負荷をかけます。
時間をソートする必要があるシナリオなどです。
リアルタイム分析ではイベントが順序不同である可能性があるため、遅延時間をサポートして、順序不同によるほとんどの不正確な計算問題を解決する必要があります。
一部の計算シナリオでは、システム時間とイベント時間の間の相互変換が含まれるため、2 つの時間変換計算方法を提供する必要があります。
実行グラフは多数のサブグラフの融合であるため、グローバルとローカルの時間レベルの管理を同時にサポートし、グラフ上のタイムラインが正しく進行することを保証する必要があります。


セキュリティベースラインは 3 つのカテゴリに分類されます。


1 つ目のカテゴリは統計的安全制限で、時間、頻度、空間、範囲、多段階統計などの一般的なセキュリティベースラインを含みます。


2 つ目はシーケンスカテゴリで、指数平滑化や周期的なセキュリティベースラインなどです。


3 つ目は機械学習のセキュリティベースラインで、クラスタリングアルゴリズムを使用したセキュリティベースラインや決定木セキュリティベースラインなどです。


ベースライン処理プロセスは主に、ベースライン学習、ベースライン検出、ベースラインルーティングの 3 つの部分に分かれ、イベントフィルタリング、タイムウィンドウ、ベースラインノイズリダクション、ベースライン管理などのプロセスが散在します。
ベースライン学習プロセスは、メッセージキューとストレージからイベントストリームを読み取ることを含み、イベントフィルタリングとタイムウィンドウ集計の後、イベントストリームにはノイズデータが含まれている可能性があり、データのノイズリダクションプロセスが必要です。
最後に、ベースライン学習プロセスは入力イベントプロセスを学習し、対応するセキュリティベースラインを生成します。
ベースライン管理プロセスの後、学習されたセキュリティベースラインは異常検出、予測、異常検出のために使用されます。
異常な行動が見つかった場合、異常イベントが生成され、後続処理フローに出力されて、後続のビジネスに使用されます。
ユーザーは使用中に、学習されたベースラインの一部を変更または削除したり、新しいベースラインを作成したりする必要がある場合があります。
これらのベースラインの追加、削除、変更は、ベースラインルーティング機能によって行われます。
ベースラインルーティングプロセスは、ユーザーがグラフ上で編集したベースラインをルーティングし、対応するグラフノードインスタンスに正確に配信します。


ベースラインサイクルは、learn、ready、close、expire の 4 つのフェーズに分かれています。


learn は学習フェーズを表し、この間にベースラインは入力イベントストリームを学習します。


ready 段階は、現在のタイムラインがベースラインの学習期限に達したことを示しますが、遅延時間のため、ベースラインは遅延時間分待機する必要があります。
この間、ベースラインは遅延イベントの学習を続けることができ、ベースラインは異常検出のために使用できます。


close は、現在のタイムラインが遅延時間に達したことを示します。
この時点で、ベースラインは入力イベントの学習を停止し、異常検出のみに使用されます。


expire は、現在のタイムラインがベースラインのタイムアウト期間に達したことを示し、ベースラインは異常検出を停止して削除する必要があります。


ベースラインの計算は、2 つの状況によってトリガーされます。


1 つ目はイベントトリガー計算で、各イベントが異常検出計算をトリガーします。


2 つ目は時間トリガー計算です。
ベースライン期間はタイムタイマーを登録し、タイムタイマーがトリガーされた後、関連するベースライン計算プロセスがトリガーされます。


ベースラインの出力は、ベースライン異常イベント出力とベースラインコンテンツ出力に分かれています。


ベースライン異常イベント出力は、ベースライン異常検出プロセス中に発生します。
異常イベントが見つかった場合、対応するイベントを出力する必要があります。


ベースラインコンテンツ出力は、ベースライン学習完了後に発生し、ベースライン自体を出力して、ベースラインの編集とベースライン自体の異常分析に使用します。


使用中、ユーザーは一部の分析とデータに基づいて、既存のベースラインを編集したり、特定のシナリオ向けの新しいセキュリティベースラインを作成したりすることがよくあります。
ベースラインを編集した後、ベースラインエンジンに配信する必要があり、これにはベースラインをオンラインで編集・更新する方法が含まれます。


まず、ベースラインは編集可能である必要があり、分析言語はベースライン編集のセマンティクスをサポートする必要があります。
同時に、ベースラインデータ構造の設計はベースライン編集のセマンティクスをサポートする必要があります。
最後に、ベースライン表示、修正、削除などの機能を含む、ベースライン編集の一連の可視化プロセスを提供する必要があり、ユーザーはページ上でベースラインを直接編集・配信できます。


次に、ベースラインはルーティング可能である必要があります。
コンパイルとグラフ最適化後の分析文とルールの実際の実行グラフは、ページ上に表示されるルールと大きく異なります。
ルーティング可能なベースラインには、コンパイル時にグローバルベースラインの更新フローグラフを構築し、ランタイムベースラインルーティング方法のセット（実行フローグラフのルーティングフロー構築、ブロードキャストと方向性ルーティングのサポート）を含み、最後に正確なベースラインデータ配信を実現する必要があります。


最後に、ベースラインは更新可能である必要があります。
明確なベースライン更新セマンティクスのセットを持ち、ベースラインの操作サイクルと計算方法を定義する必要があります。
その後、ベースライン更新プロセス中に、任意の場所で例外が発生して更新が失敗する可能性があります。
この場合、任意の場所での失敗後にユーザーに情報をフィードバックして、エラーの判断と問題の修復を行えるメカニズムのセットを設計する必要があります。


ベースライン学習プロセスでは、学習期間は通常比較的長く、先週や先月などです。
長期間の学習は通常、データ分割の問題に直面します。
たとえば、先週のデータを学習する場合、今日が水曜日だとすると、先週分のデータは 2 つの部分に分かれます。
月曜日から火曜日までのデータは履歴データストレージに保存され、水曜日以降のデータはリアルタイムです。
これには履歴データとリアルタイムデータの融合が含まれます。
ここには 3 つのケースがあります。


1 つ目は、学習対象のデータがすべて履歴データである場合で、履歴データ学習範囲の検出とオンラインベースライン更新をサポートする必要があります。


2 つ目は、学習対象のデータがすべてリアルタイムデータである場合で、自動ベースライン学習、自動ベースライン検出、自動ベースライン更新をサポートする必要があります。


3 つ目は、前述の例で挙げた最も複雑な状況で、履歴データとリアルタイムデータの融合です。
履歴データとリアルタイムデータの境界分割、ベースライン融合、重複排除をサポートする必要があります。


ベースライン学習のデータには通常、いくつかのノイズが含まれています。
これらのノイズは、ユーザーの異常な操作（ユーザーの異常なログインなど）や、データ収集プロセス中に導入された誤ったデータである可能性があります。
そのため、ノイズを排除してベースラインの精度を高め、誤検知を削減する必要があります。


データのノイズリダクションは、データ型に応じて、数値データのノイズリダクションと非数値データのノイズリダクションに簡単に分類でき、2 つの処理方法は異なります。
ノイズの種類は主に 4 つです。


1 つ目は、このサイクルのデータとの相対的な判断で、このサイクルの他のデータと比較してノイズかどうかを判断します。


2 つ目は、前のサイクルのデータと比較し、最新のサイクルのデータと比較して、ノイズかどうかを判断します。


3 つ目は、履歴データとすべての履歴データを比較して、ノイズかどうかを判断します。


最後は、ユーザーがノイズ判断ロジックを定義します。
たとえば、いくら以上または以下の場合にノイズであると設定します。
データをノイズリダクションする際、通常は関連データを保存する必要があります。たとえば、ノイズ判断に履歴データを使用する場合、いくつかの履歴キーデータを保存する必要があります。通常、履歴データは非常に多いため、ストレージを削減するために、ノイズリダクションデータ構造の最適化が必要です。ノイズリダクションに必要なキーデータの最小化やフィールドプルーニングなどです。

エンジン運用の非常に重要な部分は、リソースをどのように監視・保護するかです。3 つの側面が含まれます。

1 つ目は安定性の強化です。ベースライン実行プロセス中のメモリ使用量を動的に監視する必要があります。エンジン内で同時に数百、数千のベースラインルールが実行されている可能性があります。各ベースラインルールのメモリ使用量を監視できる必要があります。メモリ使用量が異常なルールに対しては、メモリ保護対策を講じる必要があります。たとえば、一部のデータを削除したり、隔離して、他の正常なルールの実行に影響を与えないようにする必要があります。削除時にはリソース優先度管理を使用できます。優先度が比較的低く、同時に多くのリソースを消費している場合、リソースを削減してルールの実行を軽減したり、無効化したりする可能性があります。エンジンはベースライン計算プロセスも監視しており、監視プロセス中にグラフ処理のパフォーマンスに深刻な影響を与える低速パスが見つかった場合、サブグラフ隔離によって低速パスに対応するサブグラフを隔離し、他の分析プロセスに影響を与えないようにします。

2 つ目は状態監視です。状態監視は 2 つの部分で構成されています。第 1 の部分は、エンジンが実行グラフ内のすべてのコンピューティングノードの状態データ（CPU、メモリ、ディスク、入出力など）を監視サービスに報告することです。第 2 の部分は、監視サービスが処理後、実行グラフの運用情報をルール状態情報にマッピングし、グラフ状態からビジネス状態への変換を完了することです。大規模な実行グラフと高同時実行分析タスクの場合、グラフ状態報告プロセスを最適化して、リソース消費を削減する必要があります。

3 つ目はフロー制御です。エンジンの下流ビジネスは、データベース書き込みなど、処理能力が比較的遅いプロセスである場合があります。この場合、フロー制御をサポートして、より高速な処理フローからより遅い処理フローに過度に多くのデータが入力されないようにする必要があります。これにより、過度なリソース消費とラグが発生します。フロー制御は、アクティブフロー制御、パッシブフロー制御、タイムウィンドウ関連フロー制御をサポートし、ユーザー設定または自動処理を通じて、前後の処理性能の差異によるデータ損失とシステム不安定を解決する必要があります。

ユーザーは使用中にルールの操作を行う必要がよくあります。これらの操作により、実行タスクの開始と停止が発生します。開始と停止のプロセスでは、データの整合性が前後で保たれなければならず、保存されたデータが開始と停止によって失われることはありません。

Flink 自体はタスク再起動時のデータ再読み込みをサポートしていますが、ここでの問題はベースラインエンジンではより複雑です。ユーザーがルールを無効化、有効化、または変更する可能性があるため、ルールセットの変更が発生し、それによって実行グラフの変更が発生します。再起動時に変更されていないルールは、セーブポイントから正しいデータに正しく読み込むことができます。グラフのローカル状態の安定性をサポートする必要があります。つまり、グラフ最適化プロセス中のグラフのローカル変更が他のサブグラフに影響を与えず、同時にコード生成プロセス中に安定したサブグラフの生成を保証し、コードが安定して実行され、変更されたルールはそれに関連するサブグラフのみに影響し、他の変更されていないルールは影響を受けません。

ベースライン学習プロセスでは、通常、大量の中間データが保存されます。セーブポイントとチェックポイントを高速化するために、複雑なデータ構造のシリアル化とデシリアル化を最適化し、増分状態をサポートする必要があります。エンジンサービスは通常、複数のユーザーに分析サービスを提供する必要があるため、マルチユーザー・マルチタスクの状態管理も行い、各タスクが対応する状態データと正確に関連付けられることを保証する必要があります。

4. 実践と展望

分析エンジンが提供するリアルタイムセキュリティ分析機能は、会社のビッグデータプロダクトの大部分にサービスを提供しています。たとえば、ビッグデータとセキュリティ運用プラットフォーム、状況認識、EDR、クラウドセキュリティ、産業制御インターネット、インテリジェントセキュリティなどです。これらのプロダクトのデプロイにより、中央企業、政府、銀行、公安など、約 1,000 のお客様をサポートしています。また、一般的なローカリゼーションシステムやさまざまなプライベートクラウドもサポートしています。デプロイ環境は 1 つから数百のクラスターまで及び、イベント量は数百から数百万 EPS まで及びます。また、省庁や中央企業による数百の特別行動に参加・サポートしてきました。

知識の普及とさまざまなセキュリティ脆弱性の頻発により、さまざまな攻撃手法とセキュリティ脅威が次々と現れており、より高いセキュリティ分析能力が求められています。エンジンを継続的に更新・最適化して、セキュリティを向上させる必要があります。攻撃検出能力については、より多くの優れた行動学習アルゴリズムと技術をセキュリティベースラインと継続的に統合し、セキュリティベースラインの検出能力を向上させる必要があります。同時に、エンジンの一部のプラクティスを何らかのチャネルを通じてコミュニティに還元し、より多くの人々に優れた設計とプラクティスを使用してもらいたいと考えています。