Cribl、Radiant AI SOC買収でセキュリティポートフォリオを拡大
Criblは8月19日、Radiant SecurityのAI SOC技術資産を取得した。わずか1カ月余りで2件目となるセキュリティ関連の買収だ。Google Newsの見出しはこの取引を伝えているものの、その背後にあるより大きな競争構図までは捉えていない。Criblは、一般にSIEMとして知られるセキュリティ情報・イベント管理プラットフォームが歴史的に担ってきた領域へ、テレメトリーのルーティングを超えて進出しようとしている。
Criblによれば、取得した知的財産はセキュリティアラートを自律的にトリアージし、調査し、解決を支援できる。この技術は、あらかじめ定義されたプレイブックだけに全面的に依存するのではなく、アラートごとにロジックを生成する。Criblはこれを、同社の既存テレメトリープラットフォーム上で動作するアプリケーションとして適応させる計画だ。
この戦略により、CriblはMicrosoft、Cisco傘下のSplunk、CrowdStrike、Palo Alto Networks、そして新興のAI SOCベンダーが占める領域に近づく。同時に、より難しい問いも浮かび上がる。顧客が既に時代遅れと見なしていると同社がいうクローズドスタックを再構築せずに、オープンなデータレイヤーを効果的なセキュリティ運用プラットフォームへ転換できるのか。
Criblの答えは2件の買収に基づく。Radiantは調査とアラートトリアージを加える。7月に取得したCardinalOpsは、脅威を特定するためのルールの網羅性を測定し、改善する検出エンジニアリングを加える。
これらの機能を合わせることで、Criblはデータ準備、検出設計、インシデント調査にまたがるコンポーネントを手にする。この組み合わせは、どちらか一方の取引だけよりも重要だ。セキュリティインテリジェンスをテレメトリーそのものに近づけるための、意図的な試みを示している。
Criblが取得したのは技術資産であり、会社全体ではない
CriblがRadiantのAI SOC技術資産を取得したのであって、通常の企業買収を発表したわけではないため、この正確な取引構造は重要である。
CriblによるAI SOC買収には、アラートを自律的にトリアージ、調査、解決するための知的財産が含まれる。発表では取引の財務条件は開示されなかった。また、Radiantの従業員、顧客、契約上の義務のうち、どれだけがCriblへ移るのかも説明されていない。
この点は、事業会社全体を取得することと、選定した技術資産を買うことの重要な違いを示している。完全買収では通常、会社、人員、顧客関係、負債が移転する。資産取引では買い手が取得対象をより細かく選べる一方、継続性は見えにくくなる可能性がある。
Criblは、Radiantの技術を同社のテレメトリーデータプラットフォーム上でアプリケーションとして動作するよう適応させるとしている。テレメトリーとは、アプリケーション、ネットワーク、ID、エンドポイント、インフラから生成される機械生成情報を指す。セキュリティチームは、この情報を用いて活動を把握し、不審な挙動を調査する。
Radiantの製品は、逆の側面からこの課題に取り組んでいた。アラートと関連コンテキストを取り込み、その後AIを使ってアラートをトリアージし、調査を実行する。そのシステムは証拠を収集し、活動が悪意あるものに見えるかを判断し、対応を提案するよう設計されていた。
Criblによれば、取得した技術は個々のアラートに合わせたカスタムトリアージロジックを生成する。これは、事前に記述されたプレイブックだけに基づく自動化とは異なる。定義済みのプレイブックは、エンジニアがアラート到着前にシナリオを予測し、必要な手順をコード化できることを前提とする。
動的なロジックは、未知の特徴を持つアラートに対してより柔軟に対応できる可能性がある。システムは利用可能な証拠に応じて調査アクションを選択できる。ただしCriblは、この手法が顧客、アラートソース、攻撃タイプをまたいでどれほど信頼性高く機能するかを示す独立したベンチマークを公表していない。
Radiantは、この取引に既存の現場経験をもたらした。同社は2021年に設立され、これまでAI支援型のセキュリティ運用プラットフォームを販売していた。2023年には、初期投資家の参加を得てNext47が主導した$15 million Series Aを調達している。
同社は当初、自社製品をSOCコパイロットと説明していた。この位置付けは、セキュリティ運用全体を置き換えるのではなく、アナリストを支援することに焦点を当てていた。その後のメッセージングでは、トリアージと調査プロセスのより多くを処理できる適応型AI SOCへと対象を広げた。
Criblは現在、その技術をより広範なプラットフォームへ取り込んでいる。同社によれば、完成するアプリケーションはデータの保存場所を問わず、テレメトリーに対して調査を実行するという。説明どおりに提供されれば、顧客は調査開始前に関連するすべてのレコードを別のAI SOCリポジトリへコピーする必要がなくなる。
このアーキテクチャ上の詳細が、記事の中心的な緊張関係を生む。フェデレーテッドなアプローチは顧客の選択肢を維持し、不必要なデータ移動を減らせる。一方で、ソースシステムごとに可用性、構造、保持期間、クエリ性能が異なるため、一貫した調査を難しくする可能性もある。
したがって、元のGoogle News記事が示すのは、完成した統合製品の登場ではなく、統合プロジェクトの始まりである。Criblは機能と知的財産を取得した。顧客には依然として、これらのコンポーネントが実際のセキュリティ条件下で連携して運用できるという証拠が必要だ。
Criblが今セキュリティ運用へ進出する理由
テレメトリーだけを管理しても、最も重要なセキュリティ判断を捉えきれなくなっているため、Criblはバリューチェーンの上流へ進んでいる。
Criblは、企業が運用データを収集、変換、ルーティング、検索、保存することを支援することで地位を築いた。このレイヤーは、テレメトリーを生成するシステムと、それを分析するプラットフォームの間に位置する。顧客はこれにより、コストの高い下流ツールへ送るデータをより細かく管理できる。
このモデルは、根強いエンタープライズ課題に対処する。セキュリティチームと運用チームは、すべての分析プラットフォームに経済的に保持できる量を超えるログを生成する。また、クラウドサービス、エンドポイント製品、IDシステム、ネットワークツール、独自管理インフラにまたがって業務を行っている。
ルーティングとフィルタリングにより、重複と支出を削減できる。しかし、データパイプラインはアラートが攻撃を示すかどうかを判断しない。また、検出ルールが組織が実際に直面する脅威をカバーしているかを自動的に判断するものでもない。
Criblによる7月のCardinalOps買収は、その隔たりを埋め始めた。CardinalOpsの取引により、検出網羅性を評価し、不足する保護を特定し、壊れている、またはノイズの多いルールを見つけるソフトウェアが加わった。
検出エンジニアリングは、脅威に関する知識をセキュリティ製品が実行できるロジックへ変換する。敵対者の行動を、それを特定するために必要なデータソースやルールと結び付ける。CardinalOpsはこの作業の一部を自動化し、MITRE ATT&CKなどのフレームワークに照らしてセキュリティコントロールをマッピングしていた。
RadiantはCriblをさらに一歩前進させる。CardinalOpsは、適切な検出が存在し正しく機能しているかを扱う。Radiantの技術は、こうした検出や他のセキュリティツールがアラートを生成した後に何が起きるかを扱う。
この順序は、一貫した製品の方向性を生み出す。
Criblの既存プラットフォームはテレメトリーを管理し、利用可能にする。
CardinalOpsは検出網羅性とルール品質を評価する。
Radiantの技術はアラートをトリアージし、調査を実行する。
人間のアナリストが結論をレビューし、どこまでの対応権限を自動化するかを決定する。
この流れは、取引が近い時期に実施された理由を説明する。Criblは無関係なAI機能を集めているわけではない。共通のデータ基盤を中心に、隣接する機能を組み立てている。
CriblのCEOであるClint Sharpは、セキュリティデータのサイロを中心に課題を説明した。同氏は、$121 billion規模のセキュリティ市場のあまりに多くが孤立したシステムに閉じ込められたままだと述べた。この市場規模の推計とより広範な主張はCriblによるものであり、戦略を独立して裏付けるものとして扱うべきではない。
それでも動機は明確だ。AIアプリケーションは、アクセス可能で関連性があり、適切に構造化されたコンテキストに依存する。重要なIDレコードがあるプラットフォームにあり、エンドポイントの証拠が別のプラットフォームにあり、ネットワーク履歴がさらに別の場所にある場合、セキュリティエージェントは効果的に調査できない。
従来のSIEMプラットフォームは、大量のデータを一元化することでこの問題に対処する。SIEMはその後、ルールを適用し、アラートを生成し、検索を支援し、調査を管理する。このアプローチは共通の分析環境を生むが、ストレージ費用とベンダー依存を増やす可能性もある。
Criblは異なる重心を提案している。同社のプラットフォームは、1つの分析製品がすべてのコピーを所有することを求めず、分散したテレメトリーを複数のアプリケーションで利用可能にすることを目指す。AI SOC機能はこの共有基盤の上に置かれる。
同社の従来の位置付けを考えると、この動きは特に注目に値する。2024年、Criblは報道によると$3.5 billionの評価額で$319 millionを調達した。当時、このラウンドに関する報道は、AIセキュリティ企業としてのアイデンティティではなく、データインフラに重点を置いていた。
2年後、Criblは自らをTelemetryのためのAI Platformと呼び、運用セキュリティ機能を買収している。これは単なるブランド調整ではない。製品に何を期待すべきかを、顧客、パートナー、競合他社にとって変える動きだ。
Google Newsの見出しが隠すSIEMスタックへの挑戦
Criblは、セキュリティ運用がデータとワークフローを所有する単一システムではなく、共有テレメトリー上のアプリケーション群になり得ると賭けている。
これが買収の背後にある主要な競争だ。単にCriblと特定の競合1社との対決ではない。より本質的な対立は、オープンでフェデレーテッドなテレメトリーモデルと、統合されたSIEMスタックの間にある。
従来型のSIEMは、検索、検出、相関分析、調査、レポーティングの機能を管理された環境で機能させられるよう、データを一元化する。ベンダーはそのスタック全体にわたって性能を最適化できる。顧客は一貫性を得る一方、そこから移行することは難しくなり得る。
Criblは、データは可搬性を保ち、複数のツールで利用可能であるべきだと主張する。同社のプラットフォームはレコードを異なる保存先へルーティングし、選択したデータを低コストな場所に保持し、すでに存在する場所で一部の情報を検索できる。ベンダーは現在、このレイヤーの上にセキュリティアプリケーションを追加しようとしている。
AI調査担当者には幅広いコンテキストへのアクセスが必要なため、Radiantの技術はこのモデルに適合する。Criblによれば、このソフトウェアは分散したテレメトリーに対して直接調査を実行できる。これにより組織は、エンドポイント、クラウド、ネットワークのレコードを異なる場所に保持しながらも、アラートの証拠を収集できる可能性がある。
CardinalOpsは補完的なフィードバックループを提供する。その技術は、検出網羅性が弱い場合に不足しているデータソースやフィールドを特定できる。また、ルールが機能しなくなる原因となるパースや正規化の失敗も明らかにできる。
Criblは、組織がMITRE ATT&CK手法のおよそ90 percentをカバーできるデータを収集していることを示すCardinalOpsの調査を引用している。そのSIEM検出は約21 percentしかカバーしていないと、そのベンダー調査はしている。同じ分析では、SIEMルールのおよそ13 percentが壊れているとしている。
これらの数値は有用な指標だが、CardinalOpsによるものであり、その買収企業によって再掲載されたものである。業界全体に共通する比率を確立するものではない。また、組織ごとに手法の網羅性やルールの有効性の定義も異なる。
根本的なミスマッチは、なお十分にあり得る。適切なデータを収集していても、企業が適切な検知ルールを作成し、テストし、維持しているとは限らない。アラートが生成されても、アナリストが迅速に調査するための十分なコンテキストを得られるとは限らない。
Criblが提案するプラットフォームは、この両方のギャップを対象とする。CardinalOpsは、検知ルールが意味のあるカバレッジを提供しているかを評価する。Radiantの技術は、それらの検知ルールが生成するアラートを調査する。Criblは基盤となるデータへのアクセスを提供する。
ある製造業の顧客は、この買収前にこの運用モデルの一例を説明していた。公開されたAI SOCのケーススタディで、Rehrig Pacificは外部委託のセキュリティ体制を置き換え、Radiantを用いて運用を内製化したと述べている。
この顧客によれば、平均対応時間は20～30分から約5分へ短縮された。また、アナリストは各アラートとともに必要なコンテキストの70～80%を受け取っていたという。これらは顧客およびベンダーによる報告結果であり、統制された比較ではない。
それでも、このケースは意図されたワークフローを示している。メール、クラウド、エンドポイント、ネットワーク、社内システムからのアラートが1つの環境に到着する。自動調査は、アナリストがケースを確認する前に、ホストの詳細、ユーザーアクティビティ、関連イベント、タイムラインを組み立てる。
Criblは、すべての顧客に別の孤立したデータストアの導入を求めることなく、この体験を再現したい考えだ。ここで同社の戦略は既存プラットフォームに圧力をかける。共有テレメトリ全体で調査を実行できれば、顧客が1つのSIEMに収集、保存、検知、対応のすべてを支配させる理由は薄れる。
既存ベンダーには大きな優位性がある。Microsoftは、セキュリティ運用をID、エンドポイント、クラウドサービス、ワークプレースソフトウェアと接続できる。CrowdStrikeはエンドポイントにおける深い可視性を持ち、次世代SIEMの提供を拡大している。Palo Alto Networksは、ネットワーク、クラウド、エンドポイント、自動化製品を組み合わせている。
CiscoのSplunkも、大規模な導入基盤と成熟した検索機能を有する。これらのベンダーは、すでに制御している製品群をまたいでセキュリティ機能を統合できる。顧客は、アーキテクチャの開放性よりも、その運用上の一貫性を重視する可能性がある。
したがってCriblは、柔軟性が単に選択肢を増やすだけでなく、より良い成果につながることを証明しなければならない。広範なコネクター作業、スキーマ管理、アクセスに関するトラブルシューティングを要するフェデレーテッドシステムは、複雑性を排除するのではなく移し替えるだけになり得る。
google newsで取り上げられたこの買収は、その命題を直接試すものとして捉えるのが最も適切だ。Criblは今、分散データをセキュリティ上の意思決定へ変換するために必要なロジックを、より多く保有している。同社は、自社プラットフォームがそれを予測可能な形で実行できることを示さなければならない。
動的なAI調査は信頼性のトレードオフを生む
アラートごとに固有の調査ロジックを生成すればカバレッジは広がるが、検証とガバナンスの要求も高まる。
事前定義されたプレイブックには明確な限界がある。安定したデータソースと文書化された対応手順を持つ、よく知られたアラートには有効だ。しかし、新たなクエリ、想定外の証拠、あるいはプレイブックが想定していないツール横断の推論を必要とする調査では苦戦する。
Radiantの技術は、各アラートの到着時にトリアージロジックを策定することを約束している。AIエージェントは、取得すべきレコードを判断し、関係性を特定し、不審な振る舞いを評価し、追加対応を推奨できる。理論上は、より多くのアラートカテゴリにわたってシステムを適応させられる。
同じ柔軟性がリスクも生む。固定されたプレイブックは導入前にレビューでき、既知の入力に対してテストできる。動的に生成される手順はケースごとに異なるため、包括的な事前テストは難しい。
セキュリティ調査には敵対的なデータも含まれる。攻撃者は、AIシステムが読むログフィールド、ファイル名、メッセージ、その他のコンテンツを操作する可能性がある。調査エージェントには、信頼できないテレメトリと運用上の指示を分離する制御が必要だ。
アクセスも別の懸念事項である。AI SOCアプリケーションは、機密性の高いID、エンドポイント、ネットワーク、クラウドの記録をクエリする権限を必要とする場合がある。自動対応には、アカウントの無効化やデバイスの隔離など、さらに広範な権限が必要になる可能性がある。
組織は、アプリケーションが実行できるアクション、承認の仕組み、そしてすべての判断が監査可能な記録を残すかを把握する必要がある。Criblの発表では自律的なトリアージ、調査、解決が説明されているが、統合製品に関する詳細な公開ガバナンスモデルは示されていない。
精度についても独立した測定が必要だ。誤検知の削減は価値があるように聞こえるが、過度に積極的なフィルターは悪意ある活動を除外し、偽陰性を生む可能性がある。実際の侵入を見逃すコストは、無害なアラートをエスカレーションする不便さとは大きく異なる。
有用な評価では、いくつかの問いを分けるべきだ。システムは正しい証拠を取得したか。証拠を正確に解釈したか。適切な深刻度を割り当てたか。安全な対応を推奨したか。人間のアナリストは結論に同意したか。
単一の精度パーセンテージでは、こうした違いは隠れてしまう。パフォーマンスは、データソース、アラートの種類、顧客環境、利用可能な過去のコンテキストによっても変わり得る。
Criblは別個の製品から得た技術を統合しているため、統合はさらなる不確実性を生む。CardinalOpsは検知カバレッジをマッピングし、ルールを評価する。Radiantの資産はアラートを調査する。Criblは分散システム全体のテレメトリを管理する。
これらのコンポーネントには論理的な関係があるが、買収発表だけで製品アーキテクチャが統一されるわけではない。データモデル、ID制御、デプロイメントシステム、ユーザーインターフェース、監査記録には、なお統合が必要だ。
Software Analyst Cyber ResearchのSean Sosnowskiは、CardinalOpsの取引を、Criblによるデータレイヤーの制御を自然に拡張するものと説明した。セキュリティ運用の分析における同氏のコメントは、Criblが上位レイヤーへ進出するにあたって直面する可能性のある競争の広さも強調していた。
その圧力は今後さらに高まる。Criblは、自社がSIEMおよびセキュリティ分析事業でますます競合する企業との統合を、引き続き支援しなければならない。パートナーは、技術協力を制限したり、自社のデータ制御を改善したり、統合型のパフォーマンスを強調したりして対応する可能性がある。
顧客はまた、アーキテクチャ上の主張と運用上の証拠を区別すべきだ。テレメトリの保存先で調査を実行すればコピーは減らせるが、リモートクエリは依然としてソースの可用性とレイテンシーに左右される。データは一貫しないスキーマや保持ポリシーに従う可能性がある。
ソースシステムが利用不能だったり、必要な記録が期限切れになっていたりすれば、調査は失敗し得る。フィールドが不完全であれば、誤った結論に至る可能性もある。Criblには、信頼度の指標やエスカレーションルールを含め、こうした状況に対する明確な挙動が必要だ。
資産構成には、もう1つ不明点がある。Criblは、取引後にどのRadiantの人員が技術を支援するかを公表していない。知的財産は重要だが、専門性の高いエンジニアやインシデント対応の知識が、セキュリティソフトウェアの継続的な改善を左右する場合も多い。
これらの懸念はいずれも買収を無効にするものではない。それらはCriblが提示すべき証拠を定義するものだ。同社はセキュリティツールを可能にする立場から、セキュリティ判断を下す立場へ移行しており、その変化に伴って立証の基準も高くなる。
CriblのAI SOC戦略が機能するかを示す3つのシグナル
次の試金石は実行力だ。Criblは製品を明らかにし、導入実績を証明し、そのオープンモデルが運用上の負荷に耐えて機能することを示さなければならない。
最初のシグナルは、2026年9月28日のCriblConで示される。Criblは、同イベントでプラットフォームへの追加機能をさらに共有するとしている。最も重要な詳細は、パッケージング、統合、提供時期、顧客による制御に関するものとなる。
信頼できるリリースでは、買収したRadiantの技術がCriblのプラットフォーム内でどのように提供されるかを説明すべきだ。顧客は、どのテレメトリソースをクエリできるのか、クラウド環境とセルフマネージド環境の両方で動作するのか、権限がどのようにスコープ設定されるのかを知る必要がある。
Criblはまた、Radiantの調査機能とCardinalOpsの検知エンジニアリングとの関係も明確にすべきだ。共有インターフェースよりも重要なのは、共有されたフィードバックループである。調査結果は、弱いルール、不足しているコンテキスト、ノイズの多いデータソースをチームが改善する助けとなるべきだ。
Criblが具体的なデプロイメントの詳細を備えた統合製品を提示すれば、買収の論拠はより強まる。リリース時期、ガバナンス文書、対応ワークフローを伴わないデモでは、中心的な疑問は解消されないままだろう。
2つ目のシグナルは、厳選されたケーススタディを超えた顧客導入だ。Criblによれば、そのプラットフォームはFortune 100企業の半数で利用されている。この流通基盤は、AI SOCアプリケーションが大企業に入り込む有意義な経路を与える可能性がある。
導入済み顧客へのアクセスは、運用上の信頼を保証しない。既存顧客はCriblをルーティングに使用しながら、調査はMicrosoft Sentinel、Splunk、CrowdStrike、Palo Alto Networks、または別のプラットフォーム内で継続する可能性がある。セキュリティ責任者は、この新しいアプリケーションを別個に評価するだろう。
強い証拠には、実名の本番導入、文書化されたアラート件数、独立した顧客インタビュー、複数のセキュリティ環境にわたるパフォーマンスが含まれる。結果は、検知品質とアナリストの作業負荷の両方を対象とすべきだ。
最も有用な指標には、誤検知の削減、見逃しアラート率、調査時間、アナリストによるオーバーライド頻度、手作業での再構築を必要とするケースの割合が含まれる。Criblは、リモートデータアクセスが失敗する、または不完全なコンテキストを返す頻度も開示すべきだ。
顧客全体で一貫した改善が見られれば、共有テレメトリ上でアプリケーションがより優れたパフォーマンスを発揮するというCriblの主張を裏付ける。高度に構成された導入環境でのみ限定的に成功するなら、このアプローチが依然としてサービスや顧客固有のエンジニアリングに大きく依存していることを示すだろう。
3つ目のシグナルは競合他社の反応だ。SIEMベンダーは、データへのアクセスを開放し、フェデレーテッド検索を改善し、より透明性の高いAI調査制御を追加することで、Criblの差別化を弱められる。
また、統合スタックの魅力を高めることもできる。エンドポイントセンサー、IDレイヤー、分析エンジン、対応ワークフローを制御するベンダーは、それらの製品間の相互作用を最適化できる。Criblは、ポータビリティ、より広範なソースサポート、低い切り替え摩擦でこの優位性に対抗しなければならない。
パートナーの行動にも注目する価値がある。Criblのプラットフォームは現在、多くのセキュリティベンダーと接続している。これらの統合は、同社のオープンモデルの中核をなす。何らかの制限、技術協力の縮小、競合するテレメトリ機能は、戦略を弱める可能性がある。
逆に、パートナーシップが継続すれば、顧客が依然としてコンポーザブルなセキュリティアーキテクチャを求めていることを示す。隣接市場に参入するCriblを引き続き支援する必要があると、ベンダーが判断する可能性もある。
このため、この買収は典型的なgoogle newsの資金調達や合併の記事よりも重大な意味を持つ。Criblは、セキュリティ運用における制御点が中央集権型の分析スイートから共有テレメトリプラットフォームへ移行できるかを試している。
その結果はエンタープライズの購買担当者に影響する。成功すれば、チームは既存のデータインフラを維持しながら、個別のセキュリティ機能を時間をかけて置き換えられる可能性がある。失敗すれば、既存システムへの依存を減らせないまま、別のソフトウェアレイヤーを管理することになるかもしれない。
開発者とセキュリティエンジニアは、各レイヤー間のインターフェースを注視すべきだ。必要なのは、一貫したスキーマ、制御された認証情報、完全な監査証跡、信頼性の高い障害処理である。AIによる推論は、運用上のセキュリティシステムを構成する要素の1つにすぎない。
SOC外のナレッジワーカーにとっても、これは無関係ではない。セキュリティ調査はますます、IDアクティビティ、クラウドリソース、コラボレーションシステム、業務アプリケーションを対象に含むようになっている。AIエージェントによる判断は、従業員のアクセス権や本番サービスに影響を及ぼす可能性がある。
この発表を評価するチームは、Google Newsの見出しを出発点として捉えるべきだ。正確なアセットおよび統合ロードマップをCriblに確認しよう。代表的なアラート、不完全なデータ、利用できないソース、敵対的な入力を用いて製品をテストする必要がある。
最も重要なのは、システムの結論を、経験豊富なアナリストの判断と時間をかけて比較することだ。決定的な問いは、AIが調査を生成できるかどうかではない。Criblが、完全には制御できないテレメトリ全体にわたり、その調査を正確で、統制可能かつ再現可能なものにできるかどうかである。
