Druvaのランサムウェア検知、AI支援型攻撃にAIで対抗
Druvaは9月17日、二段階のランサムウェア検知システムを発表した。AI支援型攻撃によって、悪意ある活動と日常的な変更の区別が難しくなる中での対応となる。新たなDruva ransomware detection機能はバックアップスナップショットを分析し、疑わしい暗号化を検証するとともに、管理者がよりクリーンな復旧ポイントを特定できるよう支援する。
この対立は、単純なAI対AIではない。従来の異常検知は通常と異なる挙動を見つけられるが、異常がランサムウェアによるデータ改変を証明するわけではない。どのバックアップを信頼できるかを判断する間に、セキュリティチームと復旧チームはアラートの相関分析に貴重な時間を失いかねない。
Druvaは、この不確実性を証拠で置き換えようとしている。同社のシステムは、行動モデル、ファイルレベルのフォレンジック検査、Dru MetaGraphによるIDコンテキストを組み合わせる。このアプローチは、迅速に検知できても、対応者が復元対象を確信を持って選べなければ意味が薄いという、サイバーリカバリーでよく知られた弱点にDruvaを向き合わせるものだ。
Druva、異常アラートからランサムウェアの確認へ移行
Druvaにおける中心的な変更は、不審な活動の特定から、ランサムウェアがバックアップスナップショットを改変したかどうかの確認へ移る点にある。
第1段階では、バックアップメタデータからランサムウェアに関連する挙動を調査する。こうしたシグナルには、大量のファイル名変更、不審な拡張子、身代金要求メモなどのアーティファクトが含まれる。Druvaによれば、専用のAIおよび機械学習モデルが、スナップショット全体でこれらの指標を評価する。
不審な結果がただちに確認済みのランサムウェアインシデントになるわけではない。Druvaは代わりに、影響を受けたスナップショットを第2のフォレンジック段階へエスカレーションする。この分離は、通常の管理作業やアプリケーション活動に伴って発生しうる誤報の低減を狙ったものだ。
第2段階では、基盤となるファイルを調べる。Druvaの技術ドキュメントによれば、検査にはエントロピー分析、MIMEタイプの整合性、ファイルヘッダー、構造的完全性が含まれる。
エントロピーは、ファイルの内容がどの程度ランダムに見えるかを測定する。暗号化によりランダム性が高まることは多いが、エントロピーが高いだけでは悪意を立証できない。MIME分析は、ファイルが示す形式と実際の内容を比較し、拡張子の変更によって偽装されたファイルを明らかにするのに役立つ。
Druvaはその後、これらの調査結果を相関付けたうえで重大アラートを発行する。同社のシステムは、潜在的な活動についての高重要度警告と、確認済みの影響を報告する重大アラートを区別する。
この区別は、実務的なインシデント対応上の課題に対処するものだ。変更されたファイルの急増はランサムウェアを示す可能性がある一方、移行、ソフトウェア更新、大規模な管理ジョブによって生じる場合もある。あらゆる逸脱を攻撃として扱えば、アラート疲れを招き、調査を遅らせる。
Druvaによれば、証拠はRecovery InsightsおよびSecurity Command Center内で表示される。管理者は影響を受けたスナップショットを調査し、見かけ上の感染より前のポイントを特定し、データを本番環境へ戻す前にRestore Scanを実行できる。
この機能は、VMware仮想マシン、Microsoft Azure仮想マシン、AWS EC2およびEBSワークロード向けに限定提供を開始した。Druvaによれば、Premium Securityを通じて利用可能であり、アカウントマネージャーまたはサポートケース経由での有効化が必要となる。
同社は、この機能をDruvaのクラウドバックアップアーキテクチャ内で動作するためエージェントレスだと説明している。顧客は追加のローカル検知エージェントや別個のスキャンアプライアンスを必要としない。
このアーキテクチャはインシデント時に重要となる。エンドポイントツールは無効化、操作、あるいは復旧チームから隔離される可能性がある。バックアップテレメトリーは、保護対象データに何が起きたかを理解するための別の情報源として残る。
ただし、この機能は初期侵入を防いだり、ランサムウェアの実行前に阻止したりするものではない。その価値は、不審な挙動が保護対象データに到達し、バックアップスナップショット内で可視化された後に発揮される。
このより限定的な役割は重要だ。Druva ransomware detectionは主に証拠と復旧のための機能であり、エンドポイント、ID、メール、ネットワーク防御を置き換えるものではない。
AI支援型ランサムウェアが不確実性のコストを高める
AIは攻撃の速度と変化の幅を拡大することでランサムウェアの競争を変える一方、防御側は本番システムを復旧する前に信頼できる証拠をなお必要としている。
報じられた発表は、AIを使ってより多くの経路を試し、戦術をより迅速に変える攻撃者を軸に、この製品を位置付けている。盗まれた認証情報も、悪意ある操作を正規ユーザーの活動に似せることを可能にする。
これは、すべてのランサムウェアペイロードが自律的であることを意味しない。AIは、攻撃全体を制御せずとも、作戦の複数の部分を支援できる。フィッシングの改善、スクリプトの生成、偵察の迅速化、あるいは標的環境に合わせたオペレーターの調整を助けることが可能だ。
ProofpointのAI時代のランサムウェア調査では、調査対象となったランサムウェア被害者の65%が、AIによって攻撃の効果が高まったと考えていた。同調査は、インシデントの47%が悪意あるリンクから始まったとも報告している。
これらの数値は、Druvaの対応の背景にあるIDの問題を裏付ける。多くの攻撃は、ユーザーがリンクを開く、あるいは侵入者が有効な認証情報を使用するといった、当初は正規に見える行為から始まる。
アクセスが正規に見えるようになると、孤立したセキュリティシグナルの解釈は難しくなる。変更されたポリシー、新しい権限、見慣れないアプリケーション接続は、通常の管理作業かもしれない。一方で、横移動や永続化の準備を表している可能性もある。
従来の異常検知は、探索範囲を絞り込めるため、依然として有用だ。しかしセキュリティチームは、アラートが攻撃を示すのか、どのシステムが影響を受けたのか、環境が最後に信頼できたのはいつかを、なお判断する必要がある。
復旧チームは追加の問題に直面する。最新のバックアップが自動的に最適な復旧ポイントとなるわけではない。攻撃者が数日間アクセスを維持していた場合、最近のスナップショットには侵害されたデータや悪意ある変更が保存されている可能性がある。
感染したスナップショットを復元すれば、インシデントを再開させかねない。不必要に古いスナップショットを選べば、正当な事業活動を失う可能性がある。適切な復旧ポイントはこの両極の間にあり、その特定にはバックアップジョブのステータスが正常であること以上のものが必要になる。
Druvaは、長年にわたるバックアップテレメトリーが、この判断のより安定した基盤を提供できると主張する。履歴スナップショットは時間の経過に伴う変更を明らかにし、ファイルフォレンジックはそれらの変更が暗号化に似ているかを検証できる。
このため、AI支援型ランサムウェアは従来型セキュリティ企業だけでなく、バックアップベンダーにも圧力をかけている。顧客はますます、保護されたデータが調査、検証、協調的な復旧を支えることを期待している。
Rubrik、Cohesity、Commvault、Veeamもまた、データ保護をサイバーレジリエンスの一部として位置付けている。Gartnerのベンダー比較では、これらの製品のいくつかが同じ購買カテゴリーにおける代替製品として挙げられている。
競争の焦点は、プラットフォームがイミュータブルなコピーを保存するかどうかから、それらのコピーについて何を証明できるかへ移りつつある。購入者は、データがクリーンか、どのIDが関与したか、どれほど迅速に業務を再開できるかを知りたいと考えている。
Druvaの対応はこの変化を反映している。同社のAIは、汎用的なセキュリティアシスタントとして提示されているわけではない。保護対象データがランサムウェアの影響を受けたかを判断するという、誤りのコストが高い特定の判断に適用されている。
Druva Ransomware Detection、シグナルを復旧の証拠へ変える
二段階の設計が重要なのは、広範な行動スクリーニングと、復旧を承認するために必要なより厳格な証拠を分けているためだ。
第1段階では、幅広い検知が利点となる。モデルは、変更された拡張子、追加されたアーティファクト、大量の名前変更、不審なファイル変換をスキャンできる。これらのパターンは、確立済みのシグネチャがなくても、既知のランサムウェアやその亜種を明らかにできる。
ただし、その広範さは曖昧さも生む。多くの正当なワークロードは、大規模または異例の変更を生じさせる。開発システムは見慣れないファイルタイプを生成し、データベースプロセスは大規模なデータセットを書き換え、移行は大量変更に似る場合がある。
第2段階は、この曖昧さに対するDruvaの答えだ。ファイルが暗号化または構造的な操作と整合する特性を示すかを評価する。その後、システムはアラートとともに裏付けとなる指標を提示する。
Druvaはこれを説明可能な証拠と呼ぶ。実務的には、管理者はリスクスコアだけを受け取るのではなく、なぜプラットフォームがスナップショットをエスカレーションしたのかを確認できるべきだ。
この区別は、セキュリティ運用チームとバックアップ管理者の連携を改善しうる。セキュリティアナリストは疑われる攻撃を理解し、バックアップチームは利用可能な復元ポイントを理解している。行動を起こす前に、両者は共通の記録を必要とする。
ワークフローは検知から始まるが、復旧判断で終わる。Druvaの製品説明は、このプロセスを行動検知、フォレンジック検証、サイバーリカバリーに分けている。
影響の可能性を確認した後、プラットフォームは復旧ツール内で調査結果を提示する。チームは証拠をレビューし、感染前のスナップショットを選択し、提案された復元ポイントをスキャンしてから、復元を進められる。
これは、「何かが変わった」という段階で終わるアラートより有用だ。診断を、システムを復旧させるという運用上の作業へと結び付ける。
それでも、モデルの出力はDruvaの環境内で可視化されるデータに依存する。一度も取得されなかったイベントを再構成することはできず、すべての悪意ある変更が認識可能な証拠を残すことも保証できない。
また、暗号化検知が対処するのは、現代のランサムウェアの一部にすぎない。攻撃者は、何かを暗号化する前にデータを盗み、IDを破壊し、アクセスポリシーを変更し、永続化を確立できる。一部の恐喝キャンペーンでは、データをまったく暗号化しない場合もある。
Druvaは既存サービスによって、このギャップの一部に対処している。Threat Watchは既知の侵害指標をスキャンする。Data Anomaly Detectionは異常なデータ活動をフラグ付けし、マネージド検知・対応は管理上の脅威と破壊的な操作を監視する。
新機能はこれらのツールの間に位置する。一般的な異常検知より具体的である一方、より広範なインシデント調査を置き換えるものではない。その役割は、ランサムウェアの影響を検証し、より安全な復元判断を支援することにある。
同社は「ほぼゼロ」の誤検知を主張しているが、この主張には多様な顧客環境にわたる独立したテストが必要だ。誤検知の性能は、多くの場合、ワークロードの種類、データ量、地域ごとの運用パターンによって変化する。
限定提供は、その検証に向けた管理された期間をDruvaに与える。また、当初の発表が、広く展開済みの本番機能ではなく、発展途上の機能を説明していることも意味する。
エンタープライズの購入者にとって、評価すべき問いは明確だ。Druvaは、復旧を遅らせることなく、悪意ある暗号化と大量の正当な変更を一貫して区別できるのか。
この尺度は、AIの存在そのものより重要だ。効果的なモデルは、対応者がその結論を検証できる十分な証拠を保ちながら、調査時間を短縮しなければならない。
Dru MetaGraph、調査をIDへ拡張
ファイルの証拠はランサムウェアが何を損傷させたかを示せるが、攻撃者がどのように到達したかを説明するにはIDコンテキストが必要となる。
Druvaは、脅威パイプラインを、ID、アクティビティ、データのコンテキストを結び付けるインテリジェンスレイヤー「Dru MetaGraph」と組み合わせている。このシステムは、人間のアカウントだけでなく、サービスIDやAIエージェントを含む非人間IDも対象とする。
Microsoft Entra ID、Active Directory、Oktaをまたいで関係性を描き出す。Druvaによれば、これにより対応担当者は、権限、アプリケーション、ポリシー、IDに関する変更を時系列で調査できる。
グラフが有用なのは、攻撃が単一の孤立したイベントで構成されることはほとんどないためだ。侵入者は認証情報を入手し、権限を昇格させ、永続化の仕組みを追加し、システム間を移動したうえで、保護対象データに影響を及ぼす可能性がある。
フラットなアラート一覧では、アナリストがこうした関係性を手作業で組み立てなければならない。Dru MetaGraphは、侵害されたIDを起点とした想定被害範囲を含め、その経路を接続された一連の流れとして表示することを目指す。
Druvaは、観測された挙動をATT&CK knowledge baseに対応付けるとしている。MITRE ATT&CKは、実際の攻撃者の行動を戦術と技法に整理し、セキュリティチームに調査のための共通言語を提供する。
この対応付けは、個々のイベントの背後にある目的を見分ける助けになり得る。権限変更は権限昇格を意味する可能性があり、新たな認証方式は永続化を支援するものかもしれない。
Druvaは、コンテキストを伴うビューによって調査時間を数日から数時間へ短縮できると主張する。ただし、これは企業側の主張であり、公開資料には、その時間短縮を裏付ける広範な独立ベンチマークは示されていない。
より重要な設計上の選択は、ID履歴とバックアップ履歴を結び付ける点にある。ファイルレベルのアラートは不審な暗号化を特定でき、ID記録は攻撃者がどのようにして影響を受けたリソースに到達したかを示せる。
これらのレイヤーを組み合わせることで、攻撃前の状態を確立しやすくなる。対応担当者はクリーンなデータだけでなく、信頼できるアカウント、権限、ポリシーも特定する必要がある。
永続的なアクセスを除去せずにファイルを復元すれば、攻撃者に環境へ戻る経路を残すことになる。データを検証せずにアカウントをリセットすれば、ユーザーを破損または暗号化されたシステムへ戻してしまう可能性がある。
Druvaによれば、そのシステムは個別に最適化された復旧計画を生成できる。この計画は影響を受けたオブジェクトを特定し、対応を推奨し、クリーンなスナップショットを示す。ただし、各推奨事項には依然として運用上のレビューが必要となる。
ここに、Druvaの最も明確な競争上の主張がある。SaaSバックアッププラットフォームはすでに、多数の復旧ポイントにわたる履歴データを保持している。そこにIDの関係性を加えることで、これらのスナップショットを侵害後分析のためのタイムラインへ転換できる。
同じアーキテクチャはガバナンス上の問いも生む。IDグラフには、アカウント、権限、アプリケーション、行動に関する機微な情報が含まれる。顧客は、収集範囲、保持期間、アクセス制御、地域ごとの取り扱いを理解しなければならない。
AIエージェントの登場により、この問題はさらに切迫している。非人間IDは継続的に動作し、複数のアプリケーションに接続でき、作成元となったタスクの終了後も権限を保持する可能性がある。
セキュリティチームは、正当な自動化アクションと、攻撃者によるそのIDの悪用を区別する必要がある。Druvaのグラフはコンテキストを追加できるが、コンテキストがID制御と人間による判断の必要性をなくすわけではない。
したがって本質的な競争は、Druvaとランサムウェアだけの対立ではない。セキュリティ、ID、バックアップの各チームがインシデントの異なる部分を見ている、分断された対応プロセスに対する、証拠に裏打ちされた復旧との競争である。
厳しい試練はアラート量ではなく信頼性
Druvaは、複雑なワークロード、巧妙な攻撃、暗号化を第一段階としないインシデントにおいても、その証拠が信頼できるものであることを証明しなければならない。
この製品が掲げる最も強い約束は精度だ。Druvaは、多段階の検証によって誤ったシグナルを除外し、確認済みの証拠を提供できるとしている。復旧に関する判断は事業全体に影響し得るため、この約束は慎重に検証されるべきである。
偽陽性はクリーンなスナップショットを隔離したり、復元を遅らせたりする可能性がある。偽陰性は侵害済みのデータを安全と判定し、悪意ある変更を本番環境へ戻してしまう可能性がある。
攻撃者が検知器に適応すると、リスクは高まる。一般的なランサムウェアの指標を理解する敵対者は、身代金要求文を避けたり、ファイル変更を遅らせたり、想定される閾値を下回る範囲で選択的に資産を暗号化したりできる。
AIは、変種の生成や挙動のテストを通じて、この適応を加速させ得る。そのため防御モデルは、通常業務が絶え間ないエスカレーションを引き起こすほど過敏にならずに進化しなければならない。
Druvaは、テレメトリ、脅威インテリジェンス、継続的なモデル改善を通じて検知能力を向上させるとしている。顧客は、これらの更新をどのようにテストするのか、またモデル変更がアラートの一貫性に影響するのかを問うべきだ。
また、結論ごとに提示される証拠も確認すべきである。特に緊迫した復旧時には、一般的な信頼度スコアよりも、読みやすい説明のほうが価値を持つ。
ワークロードのカバレッジも別の制約となる。初期の限定提供版は、VMware、Azure仮想マシン、AWS EC2およびEBSをサポートする。組織は多くの場合、SaaSアプリケーション、エンドポイント、データベース、コンテナ、物理システムにまたがって重要データを保有している。
Druvaはこれらの環境の一部に対して他の保護機能を提供しているが、新しい二段階ランサムウェア機能は、最初から普遍的なカバレッジを提供するものではない。購入者は、より広範なプラットフォームポートフォリオと、この機能の現時点でのサポート対象を区別すべきだ。
タイミングの問題もある。バックアップベースの分析が確認できるデータは、保護ワークフローによって取得された頻度に左右される。本番アクティビティ上で動作するセキュリティ制御はイベントをより早く観測できる一方、バックアップ分析は分離性と履歴的なコンテキストを提供する。
この二つの役割は相互補完的だ。エンドポイントおよびID制御は攻撃の阻止や封じ込めに役立ち、バックアップフォレンジックは被害を検証し、より多くの情報に基づくサービス復旧を支援できる。
どのベンダーも、この関係を誤った二者択一へ変えるべきではない。復旧インテリジェンスは、予防、監視、セグメンテーション、インシデント対応、テスト済みの継続計画の必要性をなくすものではない。
競合に関する主張にも同様の慎重さが必要である。Rubrik、Cohesity、Commvault、Veeamはいずれも、異なるアーキテクチャを用いて検知およびクリーンな復旧の機能を説明している。マーケティング上の比較が、顧客の実際のワークロードや復旧上の制約を再現することはほとんどない。
購入者にはシナリオベースのテストが必要だ。有用な評価では、代表的なスナップショットに不審なファイル変更、正常な大量処理、制御された暗号化を混在させることが考えられる。そのうえでチームは、検知品質、説明、復元時間を比較できる。
演習にはID侵害も含めるべきである。このテストでは、プラットフォームが権限変更、永続化、ラテラルムーブメント、損傷したデータを、有用な復旧シーケンスへ結び付けられるかを確認すべきだ。
運用上の使いやすさも重要である。専門家だけが解釈できる証拠では、夜間のインシデント時に小規模チームを助けられない。アラートは、不確実性を隠すことなく、行動を導かなければならない。
Druvaの発表は、推測を減らすための信頼できる仕組みを提示しているが、検証という問いに終止符を打つものではない。実際の導入環境では、システムがどの程度正確なのか、何を見逃すのか、チームがどれだけ迅速に行動できるのかを示す必要がある。
エンタープライズ購入者が次に注視すべき点
次の証拠は、さらなるAIブランディングではなく、提供範囲の拡大、独立した検知結果、顧客による復旧演習から得られるべきである。
第一のシグナルは、限定提供から広範な本番利用へと進展するかどうかである。Druvaは、より多くの顧客がいつこの機能を有効化できるのか、サポート対象ワークロードが初期のクラウドおよび仮想マシンの範囲を超えて拡大するのかを明確にすべきだ。
より幅広い提供は、多様なデータセットでも性能の一貫性が保たれる場合にのみ、製品ストーリーを強化する。遅延や限定的なカバレッジは、フォレンジックの精度を一般化することが、発表が示唆するほど容易ではないことを示すだろう。
第二のシグナルは独立した検証である。購入者は、現実的なシミュレーションに基づく復旧時間の結果とともに、偽陽性率および偽陰性率の測定結果を必要としている。
有用なベンチマークには、正常な大量変更、既知のランサムウェア、未知の変種、低速な暗号化、ファイルに触れる前にIDを変更する攻撃を含めるべきだ。また、データセットと判断閾値についても説明する必要がある。
独立した証拠は、二段階分析が信頼できる確認をもたらすというDruvaの主張を強化するだろう。大規模な手作業レビューを要する結果であれば、同システムが不確実性を明確な復旧証拠に置き換えるという考えは弱まる。
第三のシグナルは、実際のインシデントワークフローにおける顧客導入である。重要なのは、セキュリティチームとバックアップチームが同じ証拠を用いて、より迅速かつ安全な判断に到達できるかどうかだ。
顧客レポートでは、システムがどのように影響を受けたスナップショットを特定し、攻撃前のポイントを選び、提案された復元を検証し、侵害されたIDを処理したかを説明すべきである。レジリエンスの向上に関する一般的な記述だけでは、この問いに答えられない。
競合他社の対応にも注目すべきだが、機能数が比較を支配すべきではない。より意味のある試金石は、別のプラットフォームがより明確な証拠、より広いコンテキスト、またはより迅速に検証された復旧を提供できるかどうかである。
Druvaのランサムウェア検知は、AIが攻撃活動と防御分析の双方を加速させている時期に登場した。その二段階アーキテクチャはAIに限定された役割を与える。広くスクリーニングし、深く検証し、その知見を復旧へ結び付けるというものだ。
この焦点は理にかなっている。未解決の問いは、顧客環境、攻撃者の手法、IDの関係性が複雑になった際にも、Druvaがその精度を維持できるかどうかである。
この機能を評価するセキュリティリーダーは、一つの厳しい演習を実施すべきだ。クリーン、異常、悪意あるスナップショットを混在させてプラットフォームに与え、ベンダーの支援なしで対応チームに復旧を求める。プレッシャー下で証拠が正しい判断を支えられるなら、DruvaのAI対応には実用的な価値がある。チームがなおインシデントを手作業で再構築するのであれば、この製品にはさらに証明すべきことがある。
