概要
- 2021年7月の Kaseya VSA インシデントは、ベンダーおよびマネージドサービスプロバイダの問題を、下流の説明責任問題に変えた。これは、影響を受けた多くの企業が MSP の通知と復旧に依存していたが、VSA を直接運用していなかったためである。
- 公開証拠は、Kaseya が攻撃前に DIVD と協調的な開示を通じてすでに協力しており、いくつかの脆弱性が修正されていたが、2021年7月2日に REvil の攻撃者が VSA を悪用した時点で脆弱なオンプレミスシステムが依然として存在したことを示している。
- Kaseya の警告後の対応(ホステッド VSA のシャットダウン、オンプレミス顧客へのシャットダウン推奨、対応チームの招集、政府パートナーへの連絡、検出ツールのリリース)は重要であった。しかし、事前のエクスプロイト曝露低減や、下流の顧客がどの程度迅速に有用なガイダンスを受け取ったかについてのすべての疑問に答えているわけではない。
- 被害者の分母は階層的である。Kaseya は後に、直接影響を受けた顧客(その多くは MSP)が60社未満、下流の企業が1,500社未満であると述べた。これらの数字は依存関係ツリーの異なる位置を表しており、一つの数字にまとめるべきではない。
- 修復の基準は可観測性である:マネージドサービスエコシステムは、誰が曝露されたか、誰が警告を受けたか、誰がシャットダウンしたか、誰が暗号化されたか、誰が復旧指示を受け取ったか、そして VSA を直接制御できない顧客が継続性を保護するためにリスクを適時に認識できたかを示せるべきである。
検出遅延はサービスチェーンを通じて伝播した
Kaseya インシデントはしばしばサプライチェーンランサムウェア攻撃と表現される。それは大まかに正しいが、そのフレーズは具体的な説明責任の経路を隠す可能性がある。公開記録は、攻撃者が Kaseya のソフトウェアビルドを改ざんしたり、悪意のあるベンダーアップデートを配布したことを示していない。Kaseya のインシデント概要と技術的詳細は、攻撃者がオンプレミス VSA のゼロデイ脆弱性を悪用し、認証をバイパスし、コマンド実行を達成し、標準の VSA 機能を使用してマネージドエンドポイントにランサムウェアを展開したと述べている。信頼の経路は管理権限を通じており、毒されたベンダーパッケージではなかった。
その区別は検出と開示にとって重要である。VSA はリモート監視・管理ソフトウェアである。マネージドサービスプロバイダは、このようなツールを使用してデバイスをインベントリし、メンテナンスを実行し、ソフトウェアを展開し、自社の常駐技術スタッフを持たないことが多い顧客をサポートする。攻撃者が VSA サーバを制御すると、悪意のあるアクションは、動作、タイミング、ペイロード、または顧客レポートが明らかになるまで、管理アクションのように見える可能性がある。最初の明確な警告は、MSP、下流の顧客、セキュリティベンダー、ソフトウェア企業、または政府のパートナーに現れる可能性がある。これらのどの位置もチェーン全体を見ることはできない。
Kaseya の2021年7月5日のプレスリリースは、社内外の情報源が7月2日午後2時(東部時間)頃に同社に潜在的な攻撃を警告し、同社は1時間以内にホステッド VSA 環境をシャットダウンし、オンプレミス顧客にサーバをシャットダウンするよう助言したと述べている。この警告後の行動は重要であった。さらなる拡散を制限した可能性が高い。しかし、下流の説明責任分析はより長い質問をする:リスクは各層でいつ認識可能になったのか、そして警告は最初に知った層からシステムを失うであろう企業にどれだけ速やかに移動したのか?
影響を受けたパートナーから早期の報告を受けた Huntress は、イベントの概要と教訓を公開した。その説明は、MSP の報告がほぼ同時に到着したこと、共通の VSA リンク、ペイロードのステージング、クリーンアップアクション、管理機能を通じた配信を説明している。Sophos はエンドポイントと対応側から同時代の技術的説明を公開した。これらの対応者の物語は全球的な被害者数ではないが、このケースで検出遅延が分散された理由を示している。暗号化に最初に気づいた企業は、必ずしも VSA を修復する権限を持つ当事者ではなかった。
FBI のKaseya 攻撃に関する公開声明はシャットダウン指示を強化し、報告を促した。CISA と FBI は後に、この勧告 PDFを通じて共同ガイダンスを発行し、検出ツール、多要素認証、制限されたリモート管理通信、管理インターフェースの VPN またはファイアウォール保護、保護されたバックアップ、および最小特権を推奨した。これらは強力な発見後の措置である。未解決の問題は、犯罪者の時計が切れる前にどれだけの曝露を減らせたかである。
したがって、検出遅延は Kaseya 内部だけで測定できない。それは、MSP が異常な VSA 動作を認識できた点、下流の企業が自社のプロバイダのツールが経路であると認識できた点、そして公的機関がインシデントレポートをより広範な警告に変えられた点で測定されなければならない。このインシデントは集中管理プラットフォームをリレー問題に変えた。
協調的な開示は犯罪者の期限に直面した
事前のエクスプロイト記録は、簡単な非難も簡単な免罪も拒むため、例外的に重要である。DIVD の限定開示は、非営利研究グループが2021年4月に VSA の調査を開始し、4月6日に Kaseya に通知したと述べている。DIVD は、Kaseya の対応はタイムリーで関与的であり、同社は研究者と修正に取り組んでいたと述べている。それは重要である。公開証拠は、ベンダーが責任ある報告を無視したという単純な主張を支持していない。
DIVD が管理するケース記録はタイムラインの別の側面を示している。このケースには複数の脆弱性が含まれていた。いくつかは7月以前に修正された。Kaseya のホスト環境は攻撃前に関連する修正を受けていた。ランサムウェアイベントが始まった時点で、オンプレミスの VSA サーバはまだ対応が必要だった。DIVD は後に、CVE-2021-30116 を含む脆弱性の完全開示を公開し、NVD のCVE-2021-30116 エントリは現在、この問題が実際に悪用されたことを記録している。
このシーケンスは厳格な説明責任基準を生み出す。研究者と誠実に協力するベンダーでも、修復、曝露低減、顧客警告が攻撃者の再発見に勝てなければ、下流の失敗に直面する可能性がある。協調的な開示は、公開詳細の前に修正を可能にすることで被害を減らすように設計されている。また、少数の人が高影響製品が脆弱であることを知っているが、多くの運用者は行動を変えるのに十分な情報を持たない期間を生み出す。製品の特権性が高ければ高いほど、その期間は短くなるべきである。
VSA の役割は緊急性を増幅した。リモート管理製品は通常のコンテンツサイトではない。それは顧客マシンのコントロールプレーンである。インターネットに面した VSA サーバに重要な認証または認可の弱点が存在する場合、起こりうる結果は1台のサーバの侵害だけではない。それはそのサーバを信頼するすべてのエンドポイントに対する悪意のあるアクションである。したがって、暫定管理はパッチ後のオプションの強化としてではなく、開示プロセスの一部として扱われるべきである。
公開記録は、攻撃前のいくつかの未解決の質問を残している。Kaseya は7月2日以前にどの曝露された運用者に個別に連絡したのか?どのような具体的な暫定制限が要求または推奨されたのか?管理インターフェースは VPN や専用ファイアウォールルールの背後に押し込まれたのか?高リスクのオンプレミス顧客はパッチが提供されるまでシャットダウンするよう求められたのか?Kaseya は既知の曝露されたシステムが状態を変更したことをどのように確認したのか?不審なプロセス作成を通常のリモート管理作業から区別するためのテレメトリは存在したのか?これらの質問は過失を前提としていない。事前のエクスプロイト警告が VSA の爆発半径に一致したかどうかを評価するために必要な証拠を特定している。
Kaseya は後に、2021年8月4日の重要通知や追加の復旧資料などの通知を公開し、侵害検出ツールページも提供した。これらの文書はインシデント後の管理記録の一部である。それ自体で2021年6月に何が可能だったかを再構築するものではない。永続的な教訓は、特権管理ソフトウェアの協調的な開示には、公の見出しのかなり前から観察可能な曝露低減が含まれるべきであるということである。
シャットダウンアドバイスがオンプレミスの格差を露呈した
Kaseya は自らが運用する環境をシャットダウンできた。しかし、顧客が運用するすべての VSA サーバを直接シャットダウンすることはできなかった。その区別が検出・開示問題の中心である。ホステッド製品は危機時にベンダーに運用制御を与える。オンプレミス製品はベンダーに知識とコード権限を与えるが、実行中のサービスは顧客または MSP の制御下にある。Kaseya のイベントでは、それはシャットダウンメッセージが各オンプレミス運用者に届き、その後、休日週末の金曜日に行動される必要があったことを意味する。
これは単なる不便ではない。攻撃者が信頼された管理機能を使用していたため、リレーの毎分が重要であった。Kaseya のメッセージは MSP のリーダーまたは管理者に届き、その人物は「VSA をシャットダウンする」という指示が顧客管理を無効にする通常のコストを上回ると理解し、悪意のあるプロシージャがすでにキューイングまたは実行されていないことを確認する必要があった。下流の顧客はその後、自社のシステムが安全か、暗号化されているか、切断されているか、復旧待ちかを知る必要があった。リレーには技術的、ビジネス的、顧客コミュニケーションのステップが含まれていた。
共同のCISA-FBI ガイダンスは、答えが単に「パッチを適用する」ではないことを認識していた。それは VSA サーバのシャットダウン、検出ツールの実行、バックアップの保存、リモート管理通信の制限、最小特権の使用を強調した。このガイダンスはオンプレミスの現実に語りかけていた:管理サーバが危険にさらされた場合、最初の公的通知後でも、運用者が悪意のある状態をクリアしたり曝露を強化したりせずに再起動すれば、危険なままである可能性がある。
Kaseya の後のSOC 3レポートは、57のオンプレミス顧客が影響を受けたと述べている。このレポートは企業提供の保証コンテキストとして有用であるが、すべての下流企業に対する完全な独立したインシデントナラティブではない。Reuters(Investing.com が配信)は、最高経営責任者の推定として800から1,500の企業が影響を受けたと報じた。これらの数字は交換可能ではない。一つはある層の直接顧客を数え、もう一つは別の層の下流組織を数えている。
この階層的な分母は通知の質に影響する。直接の Kaseya 顧客はベンダーのガイダンスを受け取るかもしれない。MSP がサービスを提供する小規模企業は、メール、電話、ポータル通知、またはシステムが利用できなくなるまで明確な説明を受けない可能性がある。食料品店、歯科医院、地方政府機関、小売業者は VSA という用語を全く知らないかもしれない。それにもかかわらず、その継続性は VSA の状態と MSP の対応に依存していた。停止の結果を負う当事者は、チェーンの中で最も情報を得ていない当事者になる可能性がある。
そのため、マネージドサービス契約は緊急事態の前に緊急通知義務を定義すべきである。顧客は、どのリモート管理ツールが特権権限を持つか、誰がそれらをシャットダウンできるか、シャットダウン中に監視とメンテナンスはどうなるか、顧客システムをどのように隔離するか、復旧をどのように優先順位付けするか、証拠をどのように共有するかを知っておくべきである。これらの条件がなければ、最初の明確な説明責任の会話は暗号化後、すべての当事者が圧力を受けて事実が不完全な時に行われる可能性がある。
下流の分母が被害を変えた
Kaseya の直接の被害者数は総顧客ベースに比べて少なく、Kaseya はすべての顧客が影響を受けたわけではないと正しく強調した。その事実は保存されるべきである。しかし、イベントの運用形状を最小化するために使用されるべきではない。このインシデントが重要だったのは、影響を受けた直接顧客の一部がマネージドサービスプロバイダだったからである。単一の MSP が、1つの危険にさらされたコントロールプレーンを数十または数百の企業に接続する可能性がある。
スウェーデンの小売業者 Coop は、下流の継続性喪失の公的な象徴となった。Investing.com は Reuters の報道として、米国の IT プロバイダに対するサイバー攻撃により、スウェーデンチェーンが800店舗を閉鎖せざるを得なかったと伝えた。後の報道では、影響を受けた企業は復旧に数週間を要する可能性があると説明されている。これらの報告は完全な被害者リストとして扱われるべきではない。それらは、リモート管理の侵害が消費者が閉ざされたドア、利用できない支払い、中断された地域事業として経験する公共サービスにどのように到達するかを示している。
中小企業にとって、マネージドサービスは合理的である。それは、多くの小規模組織が単独で構築できない専門家の労働力、監視、バックアップ管理、パッチ適用、サポートへのアクセスを提供する。同じ集中が相関故障を生み出す。地理とセクターによって別々に見える一連の企業が、1つの MSP、1つのリモートツール、1つのバックアップパターン、1つの復旧スタッフを共有する可能性がある。その層でのランサムウェアイベントは、多くの一見独立した継続性計画を同時に失敗させる可能性がある。
公共部門の継続性も同様に影響を受ける可能性がある。地方政府、学校、公共事業、公共サービス機関は、しばしば MSP または類似の外部委託サポートに依存している。ダウンタイムの影響を受ける市民は、ツールが機関の従業員、請負業者、再販業者、ソフトウェアベンダーのいずれによって運用されていたかを気にしない。彼らはサービスの復旧を必要としている。しかし、説明責任の経路はこれらの技術的関係を通じて走り、各引き継ぎで遅延が発生する可能性がある。
ここで検出と開示が経済的になる。迅速に知った小規模企業は、システムを切断し、バックアップを保存し、従業員に警告し、支払い処理を切り替え、作業を延期し、顧客に電話することができる。暗号化後にしか知らされなかった企業は選択肢が少ない。売上の喪失、給与の混乱、顧客の不満、規制報告の不確実性、保険の事務処理に直面する可能性がある。同じ技術的エクスプロイトは、下流の当事者が有用な情報を受け取るタイミングに応じて異なる被害を生み出す。
CISA、NSA、FBI および国際パートナーは後に、マネージドサービスプロバイダと顧客の関係を保護するためのより広範なガイダンスを発行し、CISA がこの勧告通知で発表した。そのガイダンスは体系的な点を反映している:MSP のセキュリティは MSP だけの私的な問題ではない。それは、その信頼を継承する顧客にとって共有された継続性の問題である。
法執行措置は修復の証拠に取って代わらなかった
Kaseya インシデントは法執行記録も生み出した。司法省は2021年、ウクライナ人が Kaseya へのランサムウェア攻撃に関連して逮捕され起訴されたと発表した。Europol はSodinokibi/REvil に結びついた5人のアフィリエイトが排除されたと発表した。司法省は後に、Sodinokibi/REvil のアフィリエイトがより広範なランサムウェア計画での役割により量刑されたと発表した。これらの記録は攻撃者の説明責任にとって重要である。
それらは運用上の質問に答えない。刑事告発と量刑は、被告人または有罪判決を受けた者を特定し、インフラを破壊し、証拠を回収し、将来のキャンペーンを抑止することができる。しかし、どの MSP 顧客が適切なバックアップを持っていたか、どの顧客が適時に知らされたか、7月2日以前にどの VSA サーバが曝露されていたか、すべての下流組織が安全に再構築されたかは証明しない。攻撃者の説明責任とサービスの説明責任は、異なる管理に関わるため共存する。
同じ区別は議会の注目にも当てはまる。GovInfoで入手可能な下院公聴会記録は、ランサムウェア、重要サービス、民間部門の準備に関する公の懸念を捉えている。監視はパターンを浮き彫りにし、政策の必要性を明らかにすることができる。それでも、検出時計、通知内容、シャットダウン実行、復旧品質に関するエンティティレベルの証拠の代わりにはならない。
NIST のSP 800-161 Rev. 1は、より広範なサプライチェーンリスクの語彙を提供する。それはサプライヤー、製品、サービス、ライフサイクル管理をサイバーセキュリティガバナンスの一部として扱う。Kaseya のインシデントは、その語彙がマネージドサービスの運用証拠を含まなければならない理由を示している。調達チームは単に MSP がリモート管理プラットフォームを使用しているか尋ねることはできない。そのプラットフォームがどのように曝露されているか、どのように監視されているか、誰が無効化できるか、クライアントセグメンテーションがどのように機能するか、バックアップがどのように隔離されているか、インシデントがどのように報告されるか、証拠がどのように共有されるかを尋ねるべきである。
したがって、Kaseya 後の修復証拠は階層的であるべきである。Kaseya は製品セキュリティの修復、脆弱性受入の成熟度、顧客警告チャネル、高リスク展開のためのセキュアバイデフォルトの期待を示すべきである。MSP は制限された管理アクセス、多要素認証の強制、セグメンテーション、最小特権、保護されたバックアップ、クライアント通知プレイブック、ツール侵害を含む机上訓練を示すべきである。下流の顧客は、どのプロバイダツールが自社のシステムを管理できるか、それらのツールをシャットダウンしなければならない場合の継続性の代替手段を知っていることを示すべきである。
法執行の成功はこれらの記録の必要性を排除しない。ランサムウェアのアフィリエイトが逮捕されても、企業が復旧可能なバックアップを欠いている可能性がある。ベンダーがパッチをリリースしても、MSP がすべての顧客に連絡していない可能性がある。政府の勧告が正しくても、最も小さい影響を受けた企業が何が起こったのか理解していない可能性がある。説明責任は被害が着地する層に到達しなければならない。
可観測性が修復の基準である
Kaseya に対する第二のレンズの質問は、マネージドサービスが悪いかどうかではない。マネージドサービスは、そうでなければほとんどサポートを受けられない組織のセキュリティを向上させることができる。問題は、集中管理によって生み出されるリスクが、それに依存する当事者によって観察可能かどうかである。隠れたコントロールプレーンは隠れた説明責任を生み出す。
可観測性は資産の知識から始まる。各顧客は、どのリモートツールがコマンドを実行し、ソフトウェアを展開し、資格情報をリセットし、機密システムにアクセスできるかを知っているべきである。MSP は、どのサーバとテナントがその権限を持つかを知っているべきである。ベンダーは、ライセンスとテレメトリがそれを可能にする場合、どの顧客が曝露された高リスクバージョンを運用しているかを知っているべきである。公的機関は、MSP インシデントがコミュニティサービスを脅かす場合に、重要なサービスプロバイダに連絡する方法を知っているべきである。
可観測性はイベントのタイミングで継続する。有用なインシデント記録は、最初の既知のエクスプロイト、最初の内部アラート、最初の顧客報告、最初のベンダーシャットダウン指示、最初の MSP から顧客への通知、最初の下流の暗号化、最初の検出ツール結果、および影響を受けた各当事者が安定した復旧に達した時間を特定するだろう。これらのタイムスタンプがなければ、リーダーはある時点での迅速な行動を称賛しながら、別の時点での遅延を見逃す可能性がある。
可観測性はまた分母の規律を必要とする。60未満の直接顧客、57のオンプレミス顧客、最大1,500の下流企業、および無数のマネージドエンドポイントは異なるカウントである。それらは異なる説明責任の単位を記述している。直接顧客数はベンダーの曝露を示す。下流企業数は継続性の被害を示す。エンドポイント数は技術的ワークロードを示す。それらを混在させると、修復が成功または失敗した場所が不明瞭になる。
最後に、可観測性は顧客向けの言葉を必要とする。小規模企業は最初の1時間にすべてのエクスプロイトの詳細を必要としない。しかし、プロバイダのリモート管理ツールが関与したかどうか、システムを切断すべきかどうか、バックアップが安全かどうか、ファイルが暗号化されているかどうか、支払いを継続できるかどうか、従業員が特定のデバイスの使用を停止すべきかどうか、次のアップデートがいつ到着するかを知る必要がある。MSP の通知の質はベンダーのインシデントの被害プロファイルの一部である。なぜなら、ベンダーの製品が MSP の到達範囲を可能にしたからである。
Kaseya イベントは、リモート管理プラットフォームが効率と脆弱性の両方を集中させる可能性があることを示した。2021年以降の説明責任の課題は、効率を維持しながら脆弱性を可視化することである。それは、公開開示がリスクを高める場合のより迅速な私的警告、より強力なデフォルトの曝露制限、リモート管理の依存関係を名前で挙げる顧客契約、および MSP のお気に入りのツール自体が利用不可または敵対的になる可能性を想定した復旧計画を意味する。
通知チェーンには独自のサービスレベル目標が必要
このインシデントは、マネージドサービスセキュリティが修復目標だけでなく、通知サービスレベル目標を必要とする理由を示している。通常のソフトウェア脆弱性では、ベンダー勧告を受信する運用者は、多くの場合、システムが曝露されたままの場合に被害を受けるのと同じ組織である。マネージドサービスでは、運用者とリスクを負う顧客は異なる場合がある。MSP はベンダーの警告を受信する一方、小規模企業は結果のみを受信する可能性がある。そのギャップには測定可能な基準が必要である。
通知目標は分類から始めるべきである。リモート管理ツールがクライアント環境全体でコマンドを実行したり、ソフトウェアを展開したり、セキュリティ設定を変更したり、バックアップに触れたりできる場合、そのツールの深刻な脆弱性は日常的なチケットではない。それはクライアントリスクイベントである。MSP は、「プロバイダコントロールプレーンインシデント」という事前に作成されたカテゴリを持つべきであり、それはすべての技術的詳細が判明する前でもクライアントコミュニケーションをトリガーする。メッセージは範囲を限定し慎重にすることができるが、暗号化がクライアントで可視化されるまで待つべきではない。
最初の通知は攻撃者を助けるエクスプロイト詳細を公開する必要はない。それは運用上重要なことをクライアントに伝えるべきである:特権管理プラットフォームが緊急レビュー中である;プロバイダアクセスが制限される可能性がある;特定のメンテナンスタスクが一時停止される可能性がある;クライアントはバックアップを保存し、指示なしに影響を受けたマシンを再起動しないようにすべきである;緊急連絡先と次のアップデートのタイミングが利用可能である。侵害が確認された場合、通知はどのシステムが影響を受けたか、プロバイダが何をしているか、クライアントが何をすべきか、どの証拠を保存すべきかを述べるべきである。
2番目の通知は依存関係をマッピングするべきである。多くのクライアントはマネージドサービスの背後にある製品名を知らない。企業は「当社の IT プロバイダがパッチ適用を担当している」と理解していても、「VSA がすべてのワークステーションでコマンドを実行できる」とは理解していない。インシデント中、その無知は継続性の問題になる。MSP が関与するコントロールプレーンを特定しなければ、クライアントは自社の従業員、保険会社、顧客、規制当局、取締役会にイベントを説明できない。契約は、緊急時に製品の同一性をクライアントに開示できる時期と、どの程度の詳細を共有すべきかを指定すべきである。
3番目の通知はビジネス運用に対処するべきである。MSP が VSA をシャットダウンすると、日常的な監視、ソフトウェア展開、リモートサポート、一部のセキュリティ対応機能が損なわれる可能性がある。クライアントはどのサポートが利用可能かを知る必要がある。代替電話番号、チケットチャネル、緊急アクセスルール、予想される遅延が必要である。セキュリティを保護するシャットダウン指示は、サービス結果を説明しなければ、継続性に害を及ぼす可能性がある。
4番目の通知は証拠と復旧を文書化するべきである。クライアントは、自社のデバイスが暗号化されたかどうか、不審なプロシージャが実行されたかどうか、バックアップが触れられたかどうか、資格情報がローテーションされたかどうか、法執行機関や CISA のガイダンスが関連するかどうか、プロバイダが Kaseya の検出ツールまたは他のレスポンダーの証拠を使用したかどうかを知るべきである。「対応中です」とだけ受け取ったクライアントは、自社の法的、保険、顧客に関する決定を下せない。
この通知チェーンには時間設定が必要である。MSP は、確認されたプロバイダコントロールプレーンイベントから一定分数以内の最初のクライアント通知、定義された間隔ごとのフォローアップ、復旧後の書面によるクロージャ記録を約束するかもしれない。タイムラインはクライアントと重大度によって異なるが、原則はそうではない。マネージドサービスのリスクは委任されている;説明責任は委任できない。
事前承認されたシャットダウンはガバナンス管理である
Kaseya のオンプレミス VSA サーバのシャットダウン指示は、厄介な真実を露呈した:セキュリティ上安全な行動がビジネスを混乱させる行動になる可能性がある。リモート管理プラットフォームのシャットダウンは攻撃者の到達範囲を減らすが、MSP のクライアントサポートの主要な方法も取り除く可能性がある。MSP が誰がその決定を下す権限を事前に承認していなければ、対応は最悪の瞬間に停止する可能性がある。
事前承認は、誰がツールを無効化できるか、どの証拠基準の下で、クライアントにどのように伝えるかを指定すべきである。また、シャットダウン後もどの機能が利用可能かを指定すべきである。技術者は電話でクライアントをサポートできるか?代替リモートアクセスを使用できるか?代替アクセスはより安全か、より安全でないか?どのクライアント環境が緊急リモートツールに対して敏感すぎるか?どのクライアントがプロバイダエージェントの再接続の前に書面による承認を必要とするか?これらの詳細は、金曜日の午後の攻撃が緊急になるまで面倒に感じられる。
同じ論理がベンダーにも当てはまる。VSA のような製品の場合、ベンダーのホステッドシャットダウンは直接の企業管理下にあるが、オンプレミスの運用者は明確な基準を必要とする。ベンダーはサポート条件でシャットダウンを推奨または要求できるが、実行は顧客に属する。ベンダーがパッチの準備が整う前に特定のインターネットに面したオンプレミス展開が高リスクであることを知っている場合、私的エスカレーションモデルが必要である:直接的なアウトリーチ、高重大度通知、サポートケース追跡、可能な限りの確認。目標は顧客を辱めることではない。犯罪者が行動する前に、曝露されたコントロールプレーンの数を減らすことである。
シャットダウン権限はまたバックアップと相互作用する。ランサムウェア対応は取得可能で保護されたバックアップに依存するが、多くの MSP は日常サービスをサポートするのと同じ管理エコシステムを通じてバックアップを管理する。コントロールプレーンが疑わしい場合、レスポンダーはバックアップコンソール、資格情報、ストレージ、復旧手順が独立しているかどうかを知らなければならない。CISA-FBI ガイダンスは、管理の侵害が本番だけでなく復旧も脅かす可能性があるため、エアギャップまたはその他の方法で保護されたバックアップを強調した。
クライアントはインシデント中に MSP のバックアップ計画が侵害されたツールに依存していることを発見すべきではない。マネージドサービス契約は、バックアップが論理的かつ管理的に分離されているかどうか、復旧テストの頻度、誰が復旧を承認できるか、MSP の管理環境がオフラインの場合にどうなるかを説明すべきである。小規模企業にとって、その契約言語は回復力への唯一の実用的な可視性である可能性がある。
事前承認されたシャットダウンはまた保険会社と規制当局を助ける。プロバイダが文書化されたシャットダウンと通知プレイブックに従ったことを示せるクライアントは、散在するメールから決定を再構築するクライアントとは異なる立場にある。事前承認された行動の証拠は被害を排除しないが、ガバナンスを示す。また、イベント後のベンダー、MSP、クライアント、保険会社、法執行機関間の紛争を減らすことができる。
Kaseya の記録は、警告後の迅速な行動が価値があることを示している。次の基準は、決定をより早く押し進め、爆発半径が明確な場合により自動的にするべきである。リモート管理コントロールプレーンは、フェイルクローズドに設計され、縮退モードで動作するための既知の経路を持つべきである。シャットダウンに毎回カスタムの議論が必要なら、ビジネスモデルはツールが果たすセキュリティの役割を完全に価格化していない。
下流の証拠は製品記録の一部である
ソフトウェアベンダーは当然直接顧客に焦点を当てるが、マネージドサービス製品の結果はそれらの顧客の顧客ベースにまで及ぶ。つまり、下流の証拠は製品記録に属する。ベンダーは MSP がサービスを提供するすべてのエンドポイントやすべての企業を知らなくても、インシデント報告を依存関係チェーンを可能な限り保存するように設計すべきである。
最初の証拠問題は影響を受けたチェーンの同一性である。どの Kaseya 顧客が影響を受けた VSA インスタンスを運用したか?その顧客は MSP か?その VSA インスタンスはどのクライアント環境を管理していたか?曝露ウィンドウ中にどのエージェントがチェックインしたか?どのプロシージャが実行されたか?どのエンドポイントがペイロードを受け取ったか?どのエンドポイントがオフラインで、再接続時にリスクがあったか?このチェーンがなければ、カウントはあいまいになり、復旧は不均一になる。
2番目の問題は時間である。下流の企業は、ベンダーがインシデントを発見した時だけでなく、自社のシステムがいつ触られたかを知る必要がある。悪意のあるプロシージャが特定の時間に実行された場合、そのタイムスタンプはエンドポイント調査、バックアップ選択、給与決定、顧客通知の基準となる。MSP がタイミングを提供できなければ、クライアントはより広い期間を疑わしいものとして扱わなければならず、コストが増加する。
3番目の問題は証拠の管理である。ログは VSA サーバ、MSP、エンドポイント、セキュリティツール、ベンダーに存在する可能性がある。ランサムウェアイベント中、一部の証拠は削除、暗号化、上書き、または切断される可能性がある。成熟した製品は、管理サーバが侵害されてもレスポンダーが何が起こったかを再構築できるよう、高影響の管理アクションを十分に耐久性のあるものにするべきである。それは機密テレメトリを世界に公開することを要求しない。インシデント再構築のために設計することを要求する。
4番目の問題はクライアント対応の言語である。下流の企業は、規制当局、教育委員会、市長、所有者、保険会社、顧客に報告する必要があるかもしれない。技術的なベンダー速報が自社の環境が影響を受けたかどうかを述べていなければ、それを単に転送することはできない。MSP はベンダーの証拠をクライアント固有の声明に変換すべきである:範囲内、範囲外、暗号化済み、未暗号化、証拠不足のため不明、バックアップから復元、資格情報ローテーション済み、または調査中。「不明」は真実であれば許容される;知っているふりをすることは許されない。
5番目の問題は公平な配分である。ベンダー、MSP、クライアントのすべてが最終リスクに寄与する場合、証拠記録はその配分を可能にするべきである。ベンダーの脆弱性が入口を作るかもしれない。MSP のインターネット曝露やセグメンテーションが被害を拡大するかもしれない。クライアントの弱いバックアップが復旧を長引かせるかもしれない。逆に、ベンダーの警告、MSP のシャットダウン、クライアントの継続性計画がすべて被害を減らすかもしれない。説明責任は、適切な管理を評価し非難するのに十分に詳細であるべきである。
これが、下流の証拠が製品記録の一部である理由である。ベンダーが自社製品の経済的役割がより多くの組織を管理することであるなら、直接顧客が何人影響を受けたかを知るだけでは十分ではない。製品ガバナンスは依存関係ツリーを予測すべきである。インシデントテンプレート、テレメトリ、サポートエスカレーション、公開声明は、層ごとの分母(直接顧客、MSP、下流組織、エンドポイント、サービス)を保存すべきである。Kaseya イベントが画期的だったのは、これらの層がすべて同時に重要だったからである。
契約は隠れたコントロールプレーンを明示すべき
多くのマネージドサービス顧客は Kaseya VSA を直接購入しない。彼らは成果を購入する:パッチ適用されたラップトップ、動作する電子メール、到達可能なプリンター、監視されたサーバ、ヘルプデスクサポート、障害後の復旧。リモート管理製品はサービスの約束の背後に隠れている。その隠蔽は平時には効率的かもしれないが、ランサムウェアインシデント中は顧客を地図なしのままにする。自社の環境を管理できる外部システムを知らなければ、顧客は継続性リスクを判断できない。
したがって、契約は、すべての機密設定を公開しなくても、特権プロバイダツールのカテゴリを名前で挙げるべきである。顧客は、MSP がリモート監視・管理ソフトウェア、エンドポイント検出・対応、バックアップコンソール、リモートデスクトップブローカー、スクリプティングエンジン、アイデンティティ管理、クラウド管理ポータルを使用しているかどうかを知るべきである。各カテゴリについて、顧客はツールがソフトウェアを展開、コマンドを実行、アカウントをリセット、バックアップにアクセス、またはセキュリティ管理を変更できるかどうかを知るべきである。これは好奇心ではない。依存関係レジスタである。
契約はまた、ツール侵害がどのように扱われるかを述べるべきである。特権プロバイダツールが活発に悪用されている場合、MSP は顧客に通知するか?プロバイダエージェントを切断する決定は誰がするか?顧客は影響を受けたエンドポイントのリストを受け取るか?MSP は保険および法的審査のために書面による事実をどの程度迅速に提供するか?どの証拠が保持されるか?ツールが無効化された場合、どのサポートが残るか?これらの条件は、曖昧な信頼関係を説明責任のある運用モデルに変える。
小規模企業はすべての条項を交渉する力を持たないかもしれない。そのため、業界標準、公的ガイダンス、保険会社、調達テンプレートが重要である。多くのクライアントが同じ質問をすれば、MSP は反復可能な回答を構築できる。クライアントが質問しなければ、コントロールプレーンはインシデントが暴露するまで見えないままである。Kaseya イベントは、見えない管理を販売しにくくするはずである。
これは、すべての MSP が機密内部詳細をすべてのクライアントに開示しなければならないという意味ではない。セキュリティアーキテクチャは適切なレベルで説明できる:権限、依存関係、通知、証拠、復旧。クライアントはエクスプロイトコードや管理パスワードを必要としない。プロバイダのツールが侵害された場合に自社のビジネスに何が起こるか、そしてプロバイダが次に何をする義務があるかを知る必要がある。
組版に関する注記
残された未解明点
公開記録は、すべてのエクスプロイトリクエスト、すべての影響を受けた MSP、すべての下流企業の影響、すべてのクライアント通知のタイムスタンプを確定していない。攻撃者が協調的な開示プロセスから脆弱性を学んだことは証明していない。並行発見は plausibly であり、根拠のない告発に変換されるべきではない。攻撃前のすべての暫定管理や7月2日以前に連絡を受けたすべての運用者は開示されていない。後のすべての Kaseya または MSP の管理の有効性は独立して検証されていない。
これらの限界はインシデントを知り得ないものにしない。それらは、強力なマネージドサービス説明責任にまだ必要な証拠を定義する。最も強い既知の事実は十分である:研究者が深刻な VSA の弱点を非公開で報告していた;修正が進行中であった;ホストサービスは関連修正を受けていた;オンプレミスシステムは曝露されたままだった;攻撃者は VSA の権限を使用してランサムウェアを配布した;Kaseya とパートナーは緊急のシャットダウンと復旧ガイダンスを発行した;そして下流の企業は、多くの場合、自らが直接運用していないツールに起因する被害を負った。
したがって、説明責任の質問は実用的である。マネージドサービスのコントロールプレーンがリスクにさらされているとき、結果を負うすべての当事者が十分に、十分に早く、行動するのに十分な情報を見ることができるか?2021年7月、その答えは不均一だった。一部の関係者は攻撃が知られてから迅速に行動した。多くの下流組織は依然として誰か他の人の検出、誰か他の人のシャットダウン決定、誰か他の人の説明に依存していた。それが Kaseya が可視化した下流の説明責任問題である。

