Summary

  • 攻撃者は 2021 年 7 月 2 日にインターネットに面したオンプレミスの Kaseya VSA サーバーを悪用し、認証をバイパスして正規のリモート管理機能を使用して REvil ランサムウェアを配布しました。公的記録には、Kaseya のソフトウェアビルドやコードリポジトリが改ざんされたという証拠はありません。
  • Kaseya はすでに 7 件の VSA 脆弱性に関する調整された情報開示に取り組んでいました。いくつかの問題は修正済みで、関連する修正を同社の SaaS 環境に展開していましたが、攻撃が開始された時点では脆弱なオンプレミスシステムが依然として露出していました。未解決の説明責任の問題は、Kaseya が研究者を無視したかどうかではなく(研究者側は無視していないと述べています)、是正のスピード、暫定管理策、顧客への非公開警告、露出削減が製品の並外れた権限に見合っていたかどうかです。
  • 直接の被害者数は約 50〜60 の Kaseya 顧客(同社の後日の説明による)であり、この数字は運用上の実態を過小評価しています。被害者の多くはマネージドサービスプロバイダー(MSP)であったため、ランサムウェアは Kaseya の推定で 800〜1,500 の下流企業に到達しました。リモート管理プラットフォームが、侵害された 1 つの制御盤を多数のローカルな事業継続障害に転換したのです。
  • 責任は階層化されています。Kaseya は製品セキュリティ、情報開示処理、パッチ配信、危機広報を管理していました。MSP はインターネット露出、セグメンテーション、バックアップ設計、監視、顧客復旧を管理していました。中小企業の顧客は事業継続と調達の義務を負っていましたが、多くの場合、基盤となるツールに関する知識を意味ある形で持っていませんでした。政府機関は警告、対応調整、捜査、訴追に貢献しましたが、より強力な民間の管理策の必要性を排除するものではありませんでした。

このインシデントは信頼パス攻撃でした

「サプライチェーン攻撃」という言葉はここでは有用ですが、それは想定されるビルドシステムの侵害ではなく、権限の経路を説明する場合に限ります。Kaseya のインシデント概要によると、攻撃者はオンプレミス VSA 製品のゼロデイ脆弱性を悪用し、認証をバイパスして任意のコマンド実行を達成し、その後、標準的な VSA 機能を使用して管理対象エンドポイントにランサムウェアを展開しました。また、VSA コードベース自体が悪意を持って改ざんされた証拠はないとも述べられています。

この区別は説明責任の中核です。攻撃者は、歯科医院、会計事務所、レストラン、小売店、地域のサービス企業に対して、未知のプログラムを実行するよう説得する必要はありませんでした。また、Kaseya の開発パイプラインに毒入りパッケージを忍び込ませ、署名付きベンダーリリースを待つ必要もありませんでした。彼らは、すでに顧客マシンを管理する権限を与えられている選択された VSA サーバーを侵害しました。悪意あるアクションは、日常的な IT 管理の実質的な権限と共に届けられたのです。

VSA はリモート監視管理ソフトウェアです。MSP はこれを使用して、デバイスのインベントリ管理、ソフトウェアの展開、スクリプトの実行、メンテナンスの自動化、多くの顧客環境にわたる障害解決を行うことができます。これらの機能は IT サポートの単価を下げ、1 つの技術チームが、同等の専門家を単独で雇うことが経済的に難しい企業向けにシステムを維持することを可能にします。同じ設計は、特権的な配布チャネルも生み出します。もし脅威アクターが VSA サーバーを掌握すれば、規模の利点は逆転します。

影響を受けた MSP パートナーからの早期報告を受けた Huntress は、観測された攻撃チェーンを認証バイパス、任意ファイルアップロード、コード実行に整理しました。同社の調査員は、攻撃者がエンコードされたペイロードと、ログや管理者アカウントの削除を支援する 2 つ目のファイルをアップロードし、データベースプロシージャを使用してエンドポイントへの配信をスケジュールしたと報告しています。Kaseya 独自のインジケータには、agent.crt、そのデコードされた実行可能ファイル、REvil ペイロード、および侵害された VSA サーバーに対する一連の Web リクエストが記載されていました。

Sophos はエンドポイント側から結果を独自に観測しました。同社の当時の技術解説では、インターネットに面した VSA サーバーが最初の標的であり、製品の通常のソフトウェア展開権限が顧客環境への侵入経路として使用されたと説明されています。初期の対応者による被害数が異なっていたのは、異なるセキュリティ企業が異なる集団を観測していたこと、また、VSA の侵害顧客、MSP、MSP クライアント、暗号化されたマシンの区別が一貫して維持されていなかったためです。技術的な収束は、単一の早期総数よりも重要です。つまり、特権的なリモート管理がファンアウトメカニズムに転用されたのです。

これが、この出来事を「失敗したアップデート」とだけ片付けてはいけない理由です。一部のエンドポイントテレメトリや報道では、ランサムウェアを悪意のあるアップデートと表現しました。なぜなら、それが変更をプッシュするために使用されるソフトウェアを通じて届いたからです。運用上、その説明は被害者にとって理解しやすいものです。しかし管理分析にとっては、経路の方がより多くのことを明らかにします。Kaseya は REvil を含む通常のベンダーアップデートを承認していませんでした。攻撃者は顧客が操作する VSA インスタンスを制御し、それらのインスタンスに一見正規の管理タスクを実行させました。侵害されたのは委任された信頼関係だったのです。

調整された情報開示が犯罪者の期限と衝突した

インシデント前の経緯は、単純な過失の物語に抵抗します。オランダ脆弱性開示機関(Dutch Institute for Vulnerability Disclosure、DIVD)は、2021 年 4 月 1 日に VSA の調査を開始し、4 月 2 日からインターネットに面したインストールをスキャンし、4 月 6 日に Kaseya に通知しました。DIVD の限定的開示によると、Kaseya の対応は迅速で協力的でした。Kaseya は話を聞き、パッチを発行し、研究者が開発中の修正を検証することを許可しました。DIVD は、この対応を他の一部のベンダーでの経験と比較して好意的に評価しています。

この開示は、1 つの未分化な欠陥ではなく、7 つの脆弱性を対象としていました。DIVD は、4 月に修正された未認証ファイルアップロードの問題、5 月に修正された 3 つの問題、資格情報漏洩とビジネスロジックの欠陥、クロスサイトスクリプティング、二要素認証バイパスの作業が継続中であることを記録しました。DIVD が管理するケース記録によると、バージョン 9.5.7 は 6 月 26 日に CVE-2021-30116 および CVE-2021-30119 の修正を含めて Kaseya の SaaS 環境に到達しました。また、すべてのオンプレミス VSA バージョンはケース推奨の対象であり、攻撃後に Kaseya がパッチと再起動手順を提供するまで、これらのシステムをオフラインに保つべきであったと記録されています。

DIVD は後に完全な脆弱性説明を公開しました。インシデントに最も関連するエントリである CVE-2021-30116 は、VSA クライアントダウンロードプロセスに関連する資格情報への未認証アクセスと、その資格情報をセッションに変換する能力に関するものでした。National Vulnerability Database のエントリは現在、この問題が実際に悪用され、バージョン 9.5.7 より前に修正され、後に CISA の既知の悪用脆弱性カタログに登録されたことを記録しています。

したがって、公開記録は 4 つの所見を裏付けていますが、それらに一般的に付随するすべての結論を裏付けているわけではありません。

第一に、Kaseya は 7 月 2 日より前に VSA の深刻な弱点について認識していました。第二に、同社は報告された弱点のいくつかを修正済みで、研究者と積極的に協力していました。第三に、攻撃で使用された少なくとも 1 つの脆弱性は、非公開で開示されたものの中に含まれていました。第四に、同等のオンプレミス向けの修正は、犯罪者による悪用が開始される前に、一般に顧客の手に渡っていませんでした。

記録が示していないことも同様に重要です。残りの欠陥を Kaseya がどのようにランク付けしたかを説明する、問題ごとの内部リスク登録簿、エンジニアリング見積もり、エグゼクティブエスカレーション記録、または決定ログは公開されていません。パッチが利用可能になる前に、オンプレミス顧客に対して内部的に義務付けられた暫定管理策の公表リストはありません。DIVD は 6 月 4 日に特定された VSA ホストのリストを Kaseya に手渡しましたが、どの事業者が連絡を受けたか、何を伝えられたか、いつ対応したか、あるいは Kaseya がリスクのあるインターフェースが制限されたことを検証できたかどうかは、公的記録では確立されていません。また、Kaseya が脆弱性の詳細を攻撃者に漏洩したという証拠もありません。並行的な発見は十分にあり得ることであり、悪用のソースは公には未証明のままです。

これは困難ですが必要な説明責任の基準を生み出します。ベンダーは、誠実な調整された情報開示の最中に犯罪者が欠陥を悪用したというだけで非難されるべきではありません。ソフトウェアの欠陥と敵対的な再発見を完全に排除することはできません。しかし、製品の特権と下流への影響範囲は、修正の緊急性に影響を与えるべきです。多数の顧客ネットワークにわたってコマンドを実行できるインターネットに面したリモート管理サーバーの場合、重大な認証バイパスは集中リスクの緊急事態でもあります。通常のアプリケーションの重大度に合わせて設計されたパッチキューは、このような爆発範囲を持つコントロールプレーンには遅すぎる可能性があります。

開示のジレンマは現実のものでした。未パッチの認証経路を公に指定すれば、悪用が加速する可能性がありました。十分な詳細を伴わない広範な顧客警告は、攻撃者を狭い標的クラスに誘導する一方で、事業者に何を変更すべきか不明なままにする可能性がありました。DIVD がまさにこの理由で限定的開示を擁護したのです。しかし、秘密は無活動を意味する必要はありません。ベンダーは、特定可能な露出顧客に非公開で連絡し、VPN 背後の管理アクセスを要求し、一時的なフィルタリングルールを提供し、テレメトリを増強し、サーバー機能を縮小し、緊急時の移行または停止のしきい値を設定することができます。未回答の問いは、7 月 2 日より前にこれらのどれだけが行われたかであり、公開の概念実証がリリースされるべきだったかどうかではありません。

7 月 2 日:検知、停止、そして不完全な封じ込め

Kaseya の7 月 5 日の企業声明によると、内部および外部の情報源から 7 月 2 日午後 2 時(東部時間)頃に攻撃の可能性について警告を受け、同社は 1 時間以内に対応しました。同社は VSA SaaS インフラを停止し、オンプレミス顧客に自社のサーバーを停止するよう通知し始めました。Sophos は同じ時間帯の 18:00 UTC にこのキャンペーンを認識したと記録しています。Huntress は、共通の VSA リンクが明らかになる前に、3 件の MSP レポートが互いに 30 分以内に到着したと説明しています。

停止の決断は評価に値します。Kaseya には SaaS 顧客が侵害された証拠はありませんでしたが、予防措置としてホスト型サービスを運用から外しました。同社はまた、Mandiant に支援を要請し、FBI および CISA に連絡し、インジケータを配布し、7 月 3 日に侵害検知ツールをリリースしました。FBI の公式声明は、VSA サーバーを停止して侵害を報告するよう指示を強化しました。CISA-FBI 共同インシデントガイダンスは、即時措置として、検知ツールの使用、多要素認証の強制、RMM 通信の既知の IP ペアへの制限、管理インターフェースの VPN または専用ファイアウォールネットワーク背後への配置、取得可能なエアギャップバックアップの保持、最小権限の適用を追加しました。

これらの措置は更なる被害を抑制しましたが、「1 時間以内」を完全な封じ込めと誤解すべきではありません。Kaseya は自社の SaaS サービスを停止できましたが、すべての顧客運営サーバーを直接シャットダウンすることはできませんでした。MSP がメッセージを受け取り、それを信頼し、休暇期間中の金曜日に適切な担当者に連絡し、停止を完了するまで、オンプレミス VSA インスタンスは危険なままでした。実行のためにすでに準備されていた悪意のあるプロシージャも、再起動前に特定され除去される必要がありました。集中化された能力が迅速な展開を可能にしましたが、封じ込めは分散した人間のリレーに依存していたのです。

公の時系列も警告から始まり、最初の悪用からではありません。Kaseya は影響を受けたサーバー群全体での最初の悪意のあるリクエスト時刻、最初の内部テレメトリ異常、最初の顧客暗号化イベント、またはそれらのシグナル間の間隔を公表していません。また、自社の監視が、盗まれたまたは偽造されたセッションによって作成されたものから、認可された大量プロシージャを区別できたかどうかも開示していません。これらのタイムスタンプがなければ、確認後の経営陣の対応は判断できても、予防的検知の感度については判断できません。

Kaseya の「ソフトウェアへのアクセスを遮断した」という表現も、運用実態よりも広範でした。ホスト型 VSA は Kaseya のアクションによって利用不能になりました。オンプレミス VSA は顧客環境に属し、顧客のアクションが必要でした。この違いは単なる言葉遣い以上のものです。これは、セルフホスト型エンタープライズソフトウェアの分割された説明責任を明らかにしています。ベンダーはコードと修復知識を管理し、事業者は稼働中のインスタンスを管理し、下流のクライアントはどちらの当事者の製品が自社のマシンを管理しているのかさえ知らない可能性があります。

倍率はベンダーと中小企業の間にありました

Kaseya は当初、直接の顧客基盤のごく一部のみが侵害されたと強調しました。7 月 5 日の声明では、3 万 5 千以上の顧客のうち約 50 社と述べられました。後のインシデントページでは、直接の顧客は 60 社未満、下流企業は 1,500 社未満とされました。その後のSOC 3 レポートでは、57 社のオンプレミス顧客が特定されました。Reuters は、Kaseya の CEO が影響を受けた企業は 800〜1,500 社と見積もったと報じる一方、影響を受けた企業は顧客の顧客であるため正確な総数を把握するのは難しいと Kaseya が指摘したことも伝えました。

これらの数字はすべて、その定義内では真実であり得ます。これらは依存関係ツリーの異なるレベルを示しています。Kaseya の直接顧客は、MSP として 1 つの VSA サーバーを運用しているかもしれません。その MSP は数十の独立した企業を管理しているかもしれません。各企業には多数のエンドポイントがあるかもしれません。57 の侵害顧客インスタンスを数えても、コンピュータ、POS 機能、ファイル、またはスタッフ時間を失った組織の数についてはほとんど明らかになりません。逆に、影響を受けた MSP に関連する下流企業がすべてのデバイスで暗号化されたわけではないかもしれません。責任ある報告は分母を明示しなければなりません。

より重要な経済的事実は、VSA が専門家の労働力をプールするのに役立ったことです。小規模企業がマネージドサービスを購入するのは、内部 IT スタッフが高く、散発的で、採用が難しいからです。MSP はエンジニア、監視ツール、自動化、購買力をポートフォリオ全体に分散させます。この配置はセキュリティを向上させる可能性があります。有能なプロバイダーは、5 人の事業所よりも速くパッチを適用し、長時間監視し、より確実に回復できるかもしれません。

プーリングはまた、運用リスクを相関させます。100 の小規模企業は、セクターや地理的に多様に見えるかもしれませんが、1 つの MSP が 1 つの管理プラットフォームを通じてそれらすべてを管理している場合、その技術的な障害モードは重複します。ポートフォリオには隠れた共通のエクスポージャーがあります。プラットフォーム層での脆弱性は、ローカルビジネスが独立して失敗するという仮定を覆す可能性があります。

この相関は通常のサービス契約ではほとんど見えません。小規模クライアントは自分の MSP の名前を知っているかもしれませんが、リモート管理製品、ホスティングモデル、管理インターフェースの露出、下請業者、バックアップアーキテクチャ、特権アクセス設計については知らないかもしれません。製品名が挙げられても、クライアントがそれを監査する専門知識や交渉力を持っている可能性は低いでしょう。したがって、中断を被る当事者は、ソフトウェアセキュリティの決定を行う当事者から 2 段階も離れている可能性があります。

これがマネージドサービス内部の説明責任のギャップです。委任は技術的作業を専門家に移しますが、すべての損失、法的義務、顧客の苦情、給与支払い義務、または商品の損傷を自動的に移すわけではありません。システムが停止した際、中小企業は依然として従業員と顧客に直面します。MSP は復旧作業と契約上のサービスコミットメントに直面します。ソフトウェアベンダーは製品修復と評判に直面します。契約と復旧設計がこれらの結果を意図的に割り当てない限り、運用上最も露出した当事者が、最も情報を持たない当事者でもある可能性があります。

スウェーデンが依存関係を可視化した

最も明確な公共の例は、Kaseya のオフィスでも MSP のネットワーク運用センターでもありませんでした。それはスーパーマーケットのチェックアウトでした。Reuters は、スウェーデンの食料品チェーン Coop が、影響を受けた支払いシステムが動作しなかったため、7 月 3 日に全 800 店舗を閉鎖したと報じました。同チェーンは、リモートで更新されたチェックアウトツールが攻撃を受けたと述べました。後の報道では、層状のサプライヤーパスが説明されました。Coop は Visma Esscom が管理する支払いシステムに依存しており、Visma Esscom はさらに Kaseya を使用していました。

これは物理的な意味での食料供給の失敗ではありませんでした。棚、建物、スタッフ、製品は依然として存在していました。支払い処理ができなかったことで、IT 管理の侵害が小売継続性イベントに変換されました。一部の店舗は後に代替のスキャン&ペイアプリケーションを使用しましたが、技術者が場所を訪れてバックアップから支払いマシンを復旧する必要もありました。Reuters の復旧レポートは運用の非対称性を捉えました。つまり、リモート管理はインシデント前に効率的に拡張されましたが、復旧には多くのサイトでの物理的な作業が必要になる可能性があるということです。

Coop は大規模で可視性の高い下流組織でした。同じメカニズムは、選択肢が少ない小規模企業にとってはさらに厳しいものです。会計事務所は一部の作業を延期できるかもしれませんが、給与支払いや申告期限に間に合わない可能性があります。歯科医院は臨床医と機器を維持できても、スケジューリング、画像アクセス、請求ワークフローを失う可能性があります。レストランは食材とスタッフがいても、通常の支払いを受け付けられない可能性があります。地元の製造業者は発送、ラベル、または機械サポートシステムを失う可能性があります。これらの例は、このインシデントでそれぞれが発生したことを証明するものではなく、エンドポイント暗号化がデバイス数が示唆する以上に、SME ポートフォリオにおいて異なる経済的意味を持つ理由を示しています。

収益への影響は即座に始まり、技術的な復旧コストが上乗せされます。スタッフはアイドル状態でも給与が支払われるかもしれません。事業主は信頼できる連絡先データなしに顧客とコミュニケーションを取らなければならないかもしれません。MSP の技術者は長時間労働をし、多くの場合、安全性、収益、バックアップ状態によってクライアントをトリアージします。保険通知、フォレンジック保存、法的助言、交換ハードウェアが費用を追加します。復号ツールはファイルを復元できますが、すでに失われた売上、すでに消費されたスタッフの時間、すでに損なわれた信頼を元に戻すことはできません。

このインシデントはしたがって、サービス継続性の外部性を露呈しました。Kaseya の製品価格と MSP のサービス料金は上流で交渉されました。ダウンサイドの一部は、VSA アーキテクチャを選択しておらず、Kaseya の名前を聞いたことさえない下流企業に現れました。最終的なリスク負担者が関連する管理策を観察できず、それを価格付けする実用的な方法がない場合、市場の規律は弱くなります。

安全な停止自体が停止になった

予防的 SaaS 停止は拡散の可能性のある経路を 1 つ防ぎましたが、Kaseya が侵害されていないと述べた顧客から管理サービスも奪いました。これは深刻な不確実性の下では正しいトレードオフでしたが、それでも停止であり、最初の対応時間よりもはるかに長く続きました。

Kaseya が保存するインシデント更新の時系列には、変わる復旧目標が記録されています。計画されていた SaaS 展開は 7 月 6 日にブロックするインフラストラクチャの問題に遭遇しました。タイムラインは 7 月 7 日にリセットされました。同社は最終的に SaaS の復旧を開始し、7 月 11 日にオンプレミスパッチをリリースしました。7 月 12 日早朝までにすべての SaaS 顧客がオンラインに戻ったと報告しました。つまり、影響を受けていないホスト型顧客は、サービスがまだ安全と宣言できなかったために、約 9 日間 VSA の可用性を失ったことになります。

このシーケンスを単なる遅延として嘲笑すべきではありません。アクティブな悪用の後に特権的なコントロールプレーンを再起動するには、コードの 1 行を変更する以上のことが必要です。Kaseya はアクセス経路を調査し、セキュリティリリースを作成して検証し、侵害をスキャンし、政府およびインシデント対応の専門家と調整し、インフラストラクチャを強化し、事業者を準備させ、悪意のあるプロシージャの再起動を回避する必要がありました。同社の更新は、初期の復帰から一部の低使用機能を削除し、チェックを追加し、顧客からのフィードバックが実用的な問題を明らかにするにつれてランブックを改訂したことを示しています。

同時に、長期の停止は回復可能性に関する証拠です。プラットフォームは利用不能になることで迅速に脆弱性を封じ込めることができますが、それでも顧客から不可欠な管理機能を奪います。高可用性と安全な復旧は別個の特性です。緊急時の強化、クリーンな状態の検証、段階的な再起動を迅速に実行できない場合、顧客はコントロールプレーンに依存しない実行可能なモードを必要とします。

オンプレミスの再起動負担は相当なものでした。Kaseya の時系列では、事業者はサーバーを隔離し、検出ツールを実行し、OS にパッチを適用し、IIS 構成を見直し、エンドポイントセキュリティエージェントを展開し、保留中のプロシージャをクリアし、VSA セキュリティリリースをインストールし、最終チェックリストに従う必要がありました。同社のインシデント後強化ガイドは、インバウンドアクセスの制限、強力な認証、その他の環境変更を要求しました。これらは賢明な管理策でした。それらが緊急に導入されたことも、安全な製品運用がアプリケーション外部の設定と、プレッシャーの下で複雑なランブックを実行する MSP の能力に依存していたことを示しています。

成熟した MSP にとって、通常の RMM プラットフォームなしの 9 日間は、他のリモートツールへの切り替え、手動パッチ適用、電話調整、スクリプト、サイト訪問を意味するかもしれません。成熟度の低いプロバイダーにとっては、プラットフォーム自体が運用モデルになっていた可能性があります。資産インベントリ、資格情報、手順、顧客連絡先、復旧指示のすべてが利用不能なシステムを通じて最も簡単にアクセスできる場合、ツールの喪失はその喪失への対応も損なうのです。

復号は支援であり、復旧ではなかった

Kaseya は 7 月 22 日に、第三者からユニバーサル復号ツールを入手し、Emsisoft と協力して被害者を支援していると発表しました。後に、このツールは完全に暗号化されたファイルに有効であり、それを入手するために身代金を支払ったり交渉したりしていないと述べました。これらの声明は同じインシデント時系列に表示されており、公開記録は鍵の元のソースを確立していません。

復号ツールは価値がありました。まだ暗号化されたシステムを持ち、別の復旧ルートを完了していない組織の恒久的なデータ損失を減らすことができました。また、攻撃から約 3 週間後に利用可能になりました。それまでに、一部の企業はバックアップから復元したり、デバイスを再構築したり、システムを変更したりして、すでに復旧の困難な部分を吸収していました。Huntress の回顧では、被害者の間で反応が分かれたと指摘されています。ある人にとっては鍵が突破口となり、別の人にとっては手動復旧や他の決定がすでに行われた後に到着したのです。

復号は、信頼できるサービスへの復帰と同等ではありません。復元されたファイルは無傷かもしれませんが、侵害を引き起こした環境はまだクリーンアップされパッチが適用される必要があります。資格情報と管理関係はリセットが必要かもしれません。攻撃者が削除しようとしたため、ログは不完全かもしれません。復元されたエンドポイントは再接続前にチェックされなければなりません。バックログ、顧客対応、財務調整、遅延作業は暗号化イベントを生き残ります。

この区別は、ベンダーが修復を説明する方法にとって重要です。ユニバーサルキーはインシデント対応資産であり、事業中断の払い戻しではありません。バックアップはデータ可用性管理策であり、データを使用するプロセスが事業期限内に再開できることの証明ではありません。インストールされたパッチは既知の技術的経路を閉じますが、1 つの特権サービスが単一障害点になることを許したガバナンスギャップを閉じるものではありません。

説明責任はスローガンではなく管理策に属する

攻撃者は犯罪の責任を負います。公的機関は後にこの帰属をより具体的にしました。米国司法省の2021 年 11 月の起訴発表は、Yaroslav Vasinskyi が Kaseya 製品の機能を通じて REvil コードを顧客エンドポイントに展開させたと主張しました。Europol のOperation GoldDust の報告も同様に、容疑者を Kaseya 攻撃および最大 1,500 の下流企業という数字に結び付けました。2024 年、11 件の起訴に対する有罪答弁の後、連邦裁判所は Vasinskyi に対して、広範な REvil 活動に関与したとして 13 年 7 ヶ月の刑を言い渡しました(司法省)。

刑事責任は運用上の説明責任を解決しません。セキュリティガバナンスは異なる問いを投げかけます。どの当事者が、害を合理的に防止、検知、抑制、または短縮できたはずの保護手段を管理していたか?それに基づけば、説明責任は分散していますが曖昧ではありません。

当事者その当事者の影響下にある管理策インシデントによって提起された説明責任の問い
Kaseya安全な設計、脆弱性受付、修復優先度、パッチ配信、テレメトリ、製品デフォルト、顧客警告、SaaS 運用、復旧ツール緊急性と暫定管理策セットは、露出した VSA サーバーの下流権限を反映していたか?同社は後の管理策が同じクラスのリスクを軽減することを証明できるか?
MSP またはオンプレミス事業者インターネット露出、ファイアウォールと VPN ポリシー、サーバーパッチ適用、VSA 設定、権限分離、エンドポイント監視、バックアップ、顧客復旧管理プレーンは、独立した監視、制限された到達範囲、クリーンなバックアップ、テスト済みの手動フォールバックを備えた高価値生産システムとして扱われていたか?
SME 顧客プロバイダー選定、事業影響分析、オフライン手順、バックアップ要件、保険、支払いおよびコミュニケーション代替手段事業は、MSP と共に停止する可能性のある機能を理解していたか?その契約は、依存関係に基づいて行動するための十分な情報と復旧コミットメントを提供していたか?
セキュリティ研究者調整された情報開示、証拠の質、悪用の抑制、被害者通知影響を受ける事業者とベンダーに露出を減らす十分な情報が提供される間、詳細は保護されていたか?DIVD の記録は積極的な調整と攻撃後の通知を示している。
政府および法執行機関警告、インシデント調整、被害者支援、インテリジェンス、妨害、訴追、ベースラインガイダンス公的介入は、民間の製品および継続性の義務を国家に転嫁することなく、封じ込めを加速し、持続的な期待を課したか?

Kaseya は製品レベルの説明責任の最大の割合を負っています。同社はソフトウェアを設計・保守し、残りの脆弱性を認識しており、SaaS 環境を管理し、修正を作成し、製品の下流への影響範囲を小規模クライアントよりもよく理解していました。DIVD による同社の協力に対する肯定的な説明は重要であり、完全な無策という風刺画を防ぐべきです。しかし、Kaseya の修復目標と一時的な保護がリスクに見合っていたかどうかには答えていません。

MSP は展開と継続性に関する実質的な説明責任を負います。オンプレミス運用は、コード修復を Kaseya に依存させる一方で、ネットワーク露出とタイミングの管理権限を彼らに与えました。広くインターネットに開かれた管理コンソールは、専用の管理ネットワークまたは VPN に制限されたものとは異なるリスクプロファイルを持ちます。多要素認証は重要ですが、この攻撃は製品の脆弱性が MFA が依存するログインの前提をバイパスする可能性があることを示しました。独立したエンドポイント検知、アプリケーション制御、ネットワークセグメンテーション、RMM 権限を取り消すか封じ込める方法は引き続き必要です。

SME の責任はより狭いですがゼロではありません。IT のアウトソーシングは、顧客へのサービス提供、従業員への給与支払い、記録の保護、中断中のコミュニケーションという事業の義務をアウトソーシングすることと同じではありません。しかし、小規模クライアントが MSP のツールチェーンをリバースエンジニアリングすることを要求するのは非現実的です。その実際的な義務は、重要なビジネス機能を特定し、重要な下請業者や特権ツールの開示を要求し、復旧目標を尋ね、比例的な範囲で非デジタルの回避策を維持し、MSP 停止が運営ルートを残すかどうかをテストすることです。

政府の責任は運用的ではなく、可能にし強制するものです。CISA と FBI は緩和策を配布し、Kaseya と調整し、報告を奨励しました。国際的な捜査は最終的に逮捕と起訴をもたらしました。これらの行動は攻撃者の自由を減らし被害者を助けることができますが、すべてのベンダーパッチキューを監視したり、すべてのローカルレジを復旧させる公的機関はありません。国家の永続的な役割は、報告チャネルを確立し、インテリジェンス交換を改善し、調達期待を設定し、犯罪者を追跡し、市場インセンティブが失敗する分野で最低限の義務を定義することです。

契約は隠れたアーキテクチャを明らかにすべき

このインシデントは共有責任という概念を生み出したわけではありませんが、その言葉が基盤となるアーキテクチャが見えない場合にどれほど空虚になり得るかを示しました。有用な MSP 契約は、技術的な依存を情報、権限、測定可能な復旧義務に変換すべきです。

最低限、顧客はどのリモート管理およびセキュリティツールが特権アクセスを持っているか、それらがベンダーホストか MSP 運用か、どの管理インターフェースがインターネット到達可能か、監査ログがどこに保持されるか、プロバイダーが 1 つのクライアントを他から隔離できるか、メインの RMM プラットフォームが利用不能な場合にプロバイダーがどのように必須サポートを継続するかを知るべきです。これは、すべての顧客に悪用可能な詳細を開示することを要求するものではありません。顧客が相関リスクを理解するのに十分なアーキテクチャを要求するものです。

通知条件は 3 つのイベントを区別すべきです:プロバイダーまたはツールの侵害の疑い、顧客環境へのアクセスの確認、予防措置として取られた運用停止。Kaseya の SaaS 顧客は侵害が報告されませんでしたが、サービスは停止されました。顧客データ侵害の確認後にのみ通知をトリガーする契約は、主要な継続性イベントを見逃します。

復旧コミットメントも複数の時計を必要とします。インシデントを認識するまでの時間は、それを封じ込めるまでの時間ではありません。パッチをリリースするまでの時間は、MSP がそれをインストールするまでの時間ではありません。データを復号するまでの時間は、ビジネスプロセスを再開するまでの時間ではありません。意味のあるサービス契約は、プロバイダー通知、管理プレーン隔離、重要なリモートサポートの復旧、エンドポイントトリアージ、クリーンな再構築、バックログ解消の目標を定義すべきです。リモート復旧が失敗した場合にどちらの当事者が技術者を提供するかも述べるべきです。

2022 年の多国籍勧告「MSP とその顧客の保護」は、この割り当てを明示的にしています。顧客が契約上の取り決めで、安全なリモートアクセス、監視とログ記録、インシデント対応と復旧計画、認証、サプライチェーンリスク管理などの管理策をカバーするよう推奨しています。このガイダンスは Kaseya 事件よりも後であり、拘束力のある 2021 年の義務の証拠ではありませんが、成熟した共有責任が今どうあるべきかについての有用な声明です。

調達はまた、集中について尋ねる必要があります。プロバイダーはすべてのクライアントに同じ RMM、バックアッププラットフォーム、ID プロバイダー、セキュリティエージェントを使用するかもしれません。その標準化は購入される効率性の一部です。顧客は、1 つのコントロールプレーン障害が管理とバックアップの両方を無効にできるかどうか、緊急アクセスが同じ ID システムを使用するかどうか、代替ツールが真に独立しているか、単に同じスタックの別のモジュールであるかを知るべきです。

価格圧力は答えを複雑にします。小規模企業がマネージドサービスを選択する理由の一部は、冗長性が高価だからです。すべての MSP に重複プラットフォームと 24 時間体制のスタッフを維持するよう要求すれば、一部のクライアントが負担できる以上にコストが上昇する可能性があります。したがって、説明責任は演劇的ではなく比例的であるべきです。プロバイダーは、レジリエンスを証明するためにすべてのツールの二つ目のコピーを必要としません。重要な機能について文書化されたフォールバック、RMM 信頼境界外でテストされたバックアップ、最新の顧客連絡先、急な労働力に対する信頼できる計画が必要です。

約束だけでなくテスト可能な管理策

インシデント後の最良の質問は、ベンダーや MSP がセキュリティを重要と言っているかどうかではありません。評価者が変更された管理策を観察し、それを問いただせるかどうかです。Kaseya 事件は実践的な一連のテストを示唆しています。

管理プレーンの露出を減らす。すべての RMM サーバーと管理インターフェースを列挙します。どのアドレスがそれらに到達できるか、各経路が存在する理由、最後にルールが見直された時期を示します。インターネット全体に開かれたアクセスは、明示的な所有権を持つ例外であるべきです。VPN 配置だけでは、VPN ID が広範な永続的特権を持っている場合には不十分ですが、それは未認証のパブリックリーチというクラス全体を除去します。

大量アクションを目立たせる。リモート管理プラットフォームは、通常の作業と数百の顧客やエンドポイントに触れるコマンドを区別すべきです。高ファンアウトアクションには、強力な認可、明確な発信元、運用可能な場合のレート制限、使用されているプラットフォームから独立したチャネルを通じて配信されるアラートが必要です。盗まれたセッションがサーバーの全範囲を無言で継承すべきではありません。

管理プレーンをその証拠から分離する。認証、プロシージャ作成、ソフトウェア展開、アカウント削除、設定変更のログを、VSA を制御する攻撃者が消去できないストレージにエクスポートします。Huntress はローカル証拠を除去しようとする行動を観測しました。唯一の監査証跡が特権アプリケーションの隣にある場合、侵害はシステムと説明の両方を破壊する可能性があります。

権限と露出に応じてパッチを適用する。重大度スコアは入力であり、スケジュールではありません。数千のマシンを制御するプラットフォームでのリモートから悪用可能な認証欠陥は、隔離されたツールでの同じスコアよりも短い決定サイクルを要します。テストは、ベンダーが文書化されたエスカレーション、一時的管理策、所有者、目標日、顧客露出マップ、遅延があった場合の経営陣の受け入れを示せるかどうかです。

非公開の警告を検証する。調整された情報開示中、ベンダーは特定可能な露出顧客の誰が緩和策を受け取ったか、いつ配信が成功したか、管理策が実施されたかを証明できるべきです。内容は機密のままでよいです。キャンペーンの存在と完了は、パッチが公開された後に監査可能であるべきです。

顧客から顧客への伝播を制限する。MSP は、自社の RMM の侵害が自動的にすべてのクライアント内部での無制限のネットワーク移動を許可しないことを実証すべきです。エージェント特権、ネットワークセグメンテーション、アプリケーション制御、資格情報分離、クライアントごとの管理境界は、正規のツールを有用に保ちつつ、全能にしないようにすべきです。

プラットフォームなしで復旧する。VSA または同等の RMM が 1 週間使用できない状況の演習を実行します。MSP はすべての管理対象資産を見つけ、各クライアントに連絡し、資格情報を取り消し、重要なパッチを配布し、クリーンなバックアップを取得し、サイト訪問を優先順位付けできますか?SME は支払いを受け付け、顧客と通信し、作業をスケジュールし、緊急の注文を処理できますか?失敗したコンソールを開く必要がある計画は、独立した計画ではありません。

ビジネス機能で復旧を測定する。正常に復号されたエンドポイントは中間結果です。完了基準は、使用可能なレジ、アクセス可能なスケジューリングワークフロー、調整された台帳、または別の定義されたサービスであるべきです。この測定基準の変更は、技術チームがクライアントが依然として運用上閉鎖されている間にも勝利を宣言することを防ぎます。

これらの管理策は、NIST SP 800-161 Rev. 1のより広範なサプライチェーン規律と整合します。これは、サプライヤーリスクを 1 回限りのセキュリティアンケートとして扱うのではなく、企業のガバナンス、取得、評価、継続的監視の中に位置づけます。最終改訂版はインシデント後ですが、基盤となる NIST サプライチェーンプログラムと以前の版はすでに存在していました。これは、遡及的な評決としてではなく、前方の管理枠組みとして使用されるべきです。

後の保証が証明することと、しないこと

Kaseya の 2022 年 5 月 31 日に終了する期間の SOC 3 レポートには、7 月のインシデントが開示として含まれていました。57 のオンプレミス顧客が影響を受け、対応プロセスが起動され、サードパーティ調査員が関与し、SaaS は予防的に停止され、オンプレミス顧客に警告が発せられ、7 月 11 日のリリースで復旧が開始されたと述べられています。レポートは変更管理、インシデント対応、バックアップ、セキュリティ管理、監視のポリシーについても説明しています。

これは保証プロセスと後の管理環境の有用な証拠ですが、インシデント前のすべての決定の公的なフォレンジック監査ではありません。レポート自体が内部統制の固有の限界に言及し、汎用システムの説明は特定のユーザーにとって重要な側面を省略する可能性があると説明しています。ソースコードレビューの結果、脆弱性修復のサービスレベル、7 月 2 日以前に存在した正確なテレメトリ、認証バイパスがもはや大量実行を引き起こせないことを示すテスト証拠は開示されていません。

この区別は重要です。なぜなら、認証はしばしば難しい調達質問の代用として使われるからです。クリーンな保証意見は、定義された期間にわたる定義された基準のセットに対する信頼を支えることができます。しかし、深刻な脆弱性が存在しないこと、すべての製品デフォルトが安全であること、または顧客の復旧アーキテクチャが適切であることを証明することはできません。MSP および SME は、レポートをセキュリティ保証として扱うのではなく、範囲、期間、除外事項、補完的なユーザー管理策、サブサービス処理を読むべきです。

公的説明責任は、各故障モードをテスト済みの修正に結び付ける専用の行動後レビューがあればより強固になります。Kaseya は技術的インジケータ、時系列、強化ガイド、後の保証資料を公開しましたが、主要なクラウドやソフトウェアの障害後に現在発行されている最も詳細なインシデント後レポートに匹敵する完全な独立した原因レビューは公開していません。不足しているアーティファクトは謝罪ではありません。再発経路が特定され、割り当てられ、修正され、挑戦されたという証拠です。

範囲内に留めるべき主張

いくつかの一般的な解釈は証拠を超えています。

Kaseya が容易に修正可能な欠陥を行動せずに放置していたことは証明されていません。DIVD はエンゲージメントについて反対のことを述べており、情報開示期間中に複数の修正が出荷されたことを確認しています。公正な批判は優先順位付け、暫定保護策、および内部記録が公開されていないオンプレミス露出に関するものです。

すべての Kaseya 顧客または 100 万台のマシンが侵害されたことは証明されていません。Kaseya の成熟した推定は、直接顧客 60 未満、下流企業 1,500 未満でした。他の対応者のカウントは、自身の可視性と測定時点を反映しています。マシンの総数、身代金支払い、完全な経済的損失は依然として不明です。

SaaS VSA が侵害されたことは証明されていません。Kaseya は一貫して SaaS 顧客侵害の証拠は見つからなかったと述べています。SaaS は予防的に停止され、DIVD のタイムラインは関連する修正が 7 月 2 日以前にその環境に到達していたことを示しています。SaaS 顧客が経験したサービス停止は、エンドポイント暗号化と誤ってラベル付けされるべきではありません。

通常の Kaseya ソフトウェアアップデートがソースで毒されていたことは証明されていません。最も優れた公的説明は、顧客が操作する VSA サーバーの悪用に続く、標準的な展開機能の悪用です。この出来事をサプライチェーン攻撃と呼ぶことは防御可能です。なぜなら、侵害はサプライヤー関係を通じて移動したからですが、それによって事実上異なるビルド侵害を暗示すべきではありません。

ユニバーサル復号ツールが被害者の損失を消し去ったことは証明されていません。Kaseya は、完全に暗号化されたファイルに対して有効であり、それを入手するために身代金が支払われなかったと述べました。鍵の出所は Kaseya によって公的に確立されておらず、復旧作業はその到着の前後に行われました。

最後に、刑事責任はベンダー、MSP、顧客間の民事責任を割り当てるものではありません。連邦訴追は REvil アフィリエイトの行為に対する結果を確立しました。それは Kaseya のソフトウェア開発、MSP の設定、または顧客の継続性計画の妥当性を裁定しませんでした。特定の紛争では、契約条件、準拠法、事実上の因果関係、保険、損害が重要になります。

依然として不足している情報

完全な説明責任の記録には、最初の悪用と検知のタイムスタンプ、各侵害 VSA でチェーン化された正確な脆弱性、探索、侵入、展開に使用されたサーバーの数、4 月 6 日以降に割り当てられた内部重大度と修復目標、7 月 2 日以前に提供された暫定管理策が含まれるでしょう。また、DIVD の 6 月のリストにあった露出ホストのうち、何台が非公開で通知され、何台が露出を減らしたかも示すでしょう。

影響については、欠落しているデータには、暗号化されたエンドポイントの総数、国およびセクター別の被害者分布、復旧時間の中央値と裾、下流被害者による身代金支払い、バックアップの成功率、事業中断、MSP の労働、保険回収、顧客補償が含まれます。組織の公的数は有用ですが、害の強度や期間を測定するものではありません。

永続的な修復については、読者はセキュア開発の変更、認証とセッション境界、大量展開の認可、耐タンパーログ、異常検知、緊急パッチ目標、段階的復旧、オンプレミス製品の継続的テストに関する独立した証拠を必要としています。Kaseya の強化ガイダンスと保証レポートはシグナルですが、完全なチェーンを提供するものではありません。

MSP 市場にとって、欠落している分母は構造的です。どの SME がどの RMM プラットフォームに依存しているか、何台のクライアントが各コントロールプレーンを共有しているか、プロバイダーがそれなしの運用をどれくらいの頻度でテストしているかの完全な公開インベントリはありません。この不透明性は、インシデント前にシステム的集中を価格付けすることを困難にします。

2022 年の米国議会公聴会「ランサムウェアと中小企業」は、Kaseya 事件をより広範な政策問題の中に位置づけました。それは、小規模企業は深刻なサイバー露出に直面しているが、それを防止し吸収するリソースが少ないということです。公聴会記録はエクスプロイトのフォレンジックソースではなく、それが再現している一部のインシデント資料は報道からのものです。その政策関連性は、小規模企業への社会的依存と、複雑なサプライヤーを監査する限られた能力との間のギャップです。

永続的な教訓は委任された権力に関するものです

Kaseya の 7 月 2 日の対応は、より悪い結果を防ぎました。同社はホスト型顧客が侵害された証拠がないにもかかわらず SaaS を停止し、オンプレミス事業者に警告し、調査員と政府を関与させ、検知および復旧ツールを構築し、最終的にパッチと復号サポートを提供しました。DIVD の記録は、Kaseya が根底にある脆弱性研究を無視していなかったことを示しています。これらの事実は、公正な説明に含まれるに値します。

同じ記録は、公正さが対応への賞賛で終わることができない理由も示しています。4 月に非公開で知られていた脆弱性は、オンプレミス顧客が関連リリースを入手する前に悪用に結びつきました。少数の侵害された VSA インスタンスがはるかに多くの下流企業に到達しました。最も安全な対応は、影響を受けていないユーザーにとって不可欠な管理サービスを無効にしました。復旧は集中化されたツールから手作業、代替プロセス、バックアップ、訪問へと移行しました。最も深い予防的管理策が変更されたかどうかをテストするための公的証拠は依然として薄すぎます。

このインシデントの永続的な意義は、アウトソーシングが失敗したことではありません。マネージドサービスは多くの SME にとって経済的に依然として必要であり、彼らのセキュリティベースラインを引き上げることができます。教訓は、委任された技術的権力は、結果として生じる依存関係を明らかにし、統治する義務を生み出すということです。ベンダーは自社のツールの到達範囲に応じて設計し、修復しなければなりません。MSP はリモート管理を重大な結果をもたらす本番システムとして扱い、それなしで運用する準備をしなければなりません。顧客は、重要な下請業者を明らかにし、復旧をビジネス用語で定義する契約と継続性計画を必要とします。政府は、すべての中小企業が単独でソフトウェアサプライチェーンを監査できるという虚構に抵抗しつつ、報告、ベースラインガイダンス、調査、国境を越えた執行をより効果的にするべきです。

リモート管理は、遠隔の管理者をローカルに強力にすることで機能します。2021 年 7 月、その権力は誤った方向に信頼境界を越えました。説明責任とは、次の侵害されたコンソールが、すべての顧客に遭遇する前に、制限、独立した証拠、迅速な取消し、復旧経路に遭遇することを確実にすることです。