SolarWinds Orion：ビルドシステム侵害で信頼の更新がリスクに

要約

Orion キャンペーンが成功したのは、攻撃者がソフトウェア生産プロセスを侵害し、自動ビルド中に SUNBURST を挿入し、SolarWinds の通常の署名と配布の仕組みによって改変されたコンポーネントを配信させたからです。有効な署名は侵害されたリリースプロセスを認証しましたが、それによって生成されたコードが承認されたソース状態と一致していることを独立に証明したわけではありません。
影響を受けたリリースを入手した顧客は 18,000 未満かもしれませんが、その数字は後続の操作で侵害された組織の数ではありません。後の公的推定では、確認または評価された後続の侵害は米国連邦機関 9 つと非政府組織 100 未満であり、SolarWinds は別途 SUNBURST を通じてハッキングされた顧客は 100 未満と推定しています。
ロシア対外情報庁がこの諜報活動の責任を負います。それにもかかわらず、SolarWinds はビルド環境、リリースの来歴、署名経路、および 1 つの内部侵害を顧客サイトでの信頼されたコードに変換する製品アーキテクチャを管理していました。顧客と政府購入者は、セグメンテーション、ログ記録、アイデンティティの強化、調達、復旧を管理しました。説明責任は、実際に運用できた保護策について各当事者に帰属します。
法的記録は運用記録よりも狭いものです。SEC は 2023 年に SolarWinds とその最高情報セキュリティ責任者を提訴し、連邦裁判所は 2024 年にほとんどの請求を却下し、SEC は 2025 年 11 月に残りの訴訟を権利放棄付きで却下しました。この経緯は、SEC の当初の主張を証明するものでも、すべてのビルドセキュリティ上の決定が適切であったと証明するものでもありません。技術的な予防可能性、開示法、および最終的な法的責任を分離して分析しなければならない理由を示しています。

そのアップデートは、信頼インフラが指示した通りに動作した

SolarWinds インシデントは、しばしば毒入りソフトウェアアップデートと表現されます。この表現は配信方法を捉えていますが、失敗をインストーラー内に隠された通常のマルウェアのように聞こえさせる可能性があります。より重要な事実は、影響を受けたアップデートがベンダーの正規のリリース機構を通じて生成・配信されたことです。管理者は署名検証を無効にしたり、偽のダウンロードサイトにアクセスしたり、署名のない実行可能ファイルを受け入れたりする必要がありませんでした。有害なコンポーネントは SolarWinds Orion パッケージに含まれ、デジタル署名されていました。

この違いは、説明責任の分析を変えます。ソフトウェア署名は通常、配信元と転送中の整合性に対する管理手段として理解されています。署名後にパッケージが変更された場合、署名検証は失敗するはずです。しかし、署名自体は、コンパイルのために選択されたソースが承認されていたこと、コンパイラがクリーンな環境で実行されたこと、ビルドワーカーが改変されていなかったこと、または成果物がコードレビュアーが承認した内容と一致していることを証明しません。署名が適用される前に攻撃者が行為を行った場合、その署名は既に侵害された出力を忠実に保証する可能性があります。

Mandiant のSUNBURST に関する技術的開示は、バックドアを含む SolarWinds 署名付き Orion プラグインを文書化しました。このコンポーネントは最大約 2 週間待機し、環境をプロファイリングし、正規の Orion トラフィックに似せた DNS および HTTP パターンで通信し、攻撃者が被害者を選択した後にのみコマンドを取得することができました。最初のインプラントは、静かで選択的であり、ホスト製品と互換性があるように設計されていました。その目的は、すべてのインストールを一度に破壊することではなく、多くのネットワーク内に信用できる選択肢を配置し、そのうちのごく一部のみを行使することでした。

これが、Orion が一般的に顧客の構内にインストールされていたにもかかわらず、この事象がクラウド依存性および公共継続性の記録に属する理由です。Orion は、オンプレミス、クラウド、ハイブリッド環境にわたるインフラストラクチャを監視・管理していました。後続の活動は、フェデレーション ID や Microsoft 365 リソースに到達する可能性がありました。信頼関係はサービス依存関係のように機能していました。顧客は継続的にメンテナンスされるベンダー製品に依存し、ベンダーが作成したアップデートを受け入れ、重要なシステムを観察または管理できる場所にそのソフトウェアを配置しました。実行可能ファイルの場所は、それを生成したリモートのソフトウェア工場への依存を排除しませんでした。

また、主な公共の被害は従来型の停止ではありませんでした。連邦政府のメールや運用システムが、ある目に見える日に一斉に機能停止したわけではありません。その代わり、この侵害は機密性、ID 保証、証拠の信頼性、そしてどの通信や決定が観察されたかを知る能力を損ないました。公共セクターの継続性には、信頼性を防御できるシステム上で政府業務を遂行する能力が含まれます。ネットワークが利用可能なままでも、それが支える公共機能が戦略的に露出する可能性があります。

公開記録が確立していること

最も信頼できる説明は、異なる組織的インセンティブを持つ情報源から得られます。SolarWinds のインシデント開示および証券取引委員会（SEC）への提出書類、CrowdStrike と Mandiant の技術分析、CISA、NSA、FBI、および影響を受けた機関の記録、GAO による連邦政府の対応レビュー、議会証言、そして後の裁判記録です。これらはすべての疑問に答えるわけではありませんが、いくつかの中核的事実を確立しています。

第一に、高度な攻撃者が SolarWinds の環境に長期間アクセスし、Orion の生産プロセスを研究するのに十分な時間を維持していました。SolarWinds の 2021 年 5 月の調査更新によると、同社は最初の侵入がいつ、どのように行われたかを正確に特定できませんでした。同社は、認証情報の侵害と、2019 年 10 月のテスト実行前の少なくとも 9 か月間にわたる、ソフトウェア開発環境および Microsoft 365 を含む内部システムへの持続的なアクセスの証拠を報告しました。同社は、可能性のある侵入経路をサードパーティのゼロデイ、パスワードスプレーなどの総当たり攻撃、またはソーシャルエンジニアリングに絞り込みましたが、そのうちの 1 つを証明したとは主張しませんでした。

第二に、有害な変更は自動ビルド環境で行われ、Orion のソースリポジトリへの恒久的な変更としてコミットされませんでした。これは言い訳のための技術的詳細ではありません。失敗した信頼境界を特定するものです。ビルドの前後でリポジトリを比較するレビュアーは、クリーンなソースを確認できる一方で、ビルドワーカーがコンパイル中に一時的に悪意のあるファイルに置き換えていました。したがって、ソースレビューのみに焦点を当てた管理策では、生成された成果物の相違を見逃すことになります。

第三に、攻撃者は運用バックドアを展開する前に、ビルドを変更する能力をテストしていました。SolarWinds の 2021 年 1 月の初期ビルドシステム調査結果では、当時知られていた最も初期の疑わしい内部活動を 2019 年 9 月、2019 年 10 月の Orion リリースでのテスト変更、2020 年 2 月 20 日から始まる SUNBURST の注入、2020 年 6 月の環境からの悪意のあるコードの削除としています。その後の同社の報告では、10 月のテストと 3 月から 6 月の配布期間を維持しつつ、アクセスの証拠をさらに遡らせています。

第四に、影響を受けた Orion バージョンは通常のチャネルを通じて配布されました。SolarWinds の2020 年 12 月 14 日の Form 8-Kでは、関連期間中にダウンロード、実装、または更新された製品に脆弱性が含まれており、影響を受けたリリースをインストールした可能性のある顧客は 18,000 未満と推定されるとしました。2020 年のForm 10-Kでは、SUNBURST が 2020 年 3 月から 6 月にリリースされたビルドに注入されたと説明し、影響を受けたソフトウェアは顧客の構内にインストールされたこと、および悪用された件数は影響を受けたバージョンをインストールした可能性のある件数よりも大幅に少ないことを強調しました。

第五に、FireEye は 2020 年 12 月に自社への侵入を調査中に、より広範なキャンペーンを発見しました。公開記録には、顧客が受け取る前に SolarWinds のリリース保証や連邦境界プログラムが侵害されたビルドを検出したことは示されていません。この検出ギャップは、通知後の SolarWinds の対応の良し悪しとは無関係に重要です。管理策は、生産中に危険な状態を表面化できなかったとしても、危機対応中にうまく機能する場合があります。

第六に、米国政府は後にこのキャンペーンをロシア対外情報庁（SVR）によるものと正式に特定しました。CISA の2021 年 4 月の共同勧告通知には、米国による特定と、それに対応する NSA・CISA・FBI のガイダンスが記録されています。英国もまた、SVR がこの作戦に関与したと公に関連付けました。特定は、敵対的攻撃者の責任と地政学的背景を確立しますが、ベンダーや顧客の保護策が予見可能なサプライチェーン攻撃のクラスに見合ったものであったかどうかには答えていません。

3 つの重要な事項は境界が定められています。SolarWinds への最初の侵入経路は、引用した同社の最終更新では証明されませんでした。公開記録は、後続のアクセスのために選択されたすべての組織や、それらのネットワークから取得されたすべての項目を明らかにしていません。また、影響を受けたアップデートは、組織がインタラクティブな侵害を受けたことを証明するものではありません。これらのギャップには、分析の麻痺ではなく、慎重な表現が必要です。

偵察から署名されたバックドアまで

このキャンペーンが忍耐強かったのは、標的が単なるサーバーではなく、反復可能な産業プロセスだったからです。

攻撃者はまずアクセスと理解を必要としました。ビルド環境には、コンパイラ、依存関係ストア、認証情報、オーケストレーションツール、署名インターフェース、リリーススクリプト、および多くの中間ファイルが含まれています。これらの複雑さが機会を生み出しますが、無差別な改ざんはノイズを発生させます。コンパイルの失敗、再現性の不一致、予期しないソース差分、または不正な形式のパッケージは、エンジニアに警告を発する可能性があります。したがって、攻撃者は、Orion のビルドがいつ実行されるか、どのソースファイルがインプラントを運ぶことができるか、そのファイルがどのように最終プラグインに到達するか、そして製品を不安定にしない方法を学ぶ必要がありました。

2019 年 10 月のテストは、振り返ってみると重大な警告でした。これは、攻撃者が運用ペイロードをコミットする前に注入経路を検証していたことを示しています。安全な生産設計では、ビルド中にのみ存在するテスト変更は、成果物の比較、隔離されたビルダーモニタリング、来歴チェック、または決定論的なリリース管理を通じて依然として検出されるべきです。テストが侵入者を露呈させることなくリリースに進んだという事実は、ビルド出力が期待されるソースから逸脱しても進行できることを示していました。

CrowdStrike のSUNSPOT 分析がそのメカニズムを説明しています。SUNSPOT はMsBuild.exeを監視し、コマンドライン情報を検査して Orion ソリューションを認識し、製品のビルド中にInventoryManager.csを悪意のあるバリアントに置き換えました。元のファイルを保持し、後で復元できるようにしていました。ビルドの失敗を回避するための保護策と、明らかに壊れたコンパイルを残すのではなく、侵入者がきれいに停止できるように設計された動作が含まれていました。この設計は、開発者の疑いを主要な危険として扱っていました。

結果として生じた悪意のあるコードは、SolarWinds.Orion.Core.BusinessLayer.dll内の SUNBURST となりました。置換がビルド中に行われたため、最終パッケージは通常の製品出力としてその後のパッケージングと署名のステップを通過できました。署名は本物でしたが、その背後にある来歴の主張は不完全でした。

インストールされると、SUNBURST は実行を遅延させ、分析を示す可能性のある環境条件をチェックしました。被害者固有の DNS クエリを生成し、どのビーコンがより積極的なコマンド＆コントロールに進むかをオペレーターが決定できるようにしました。Mandiant の追加の技術分析では、アンチ分析チェック、ドメイン生成動作、コマンドモード、および正規の Orion 設定に状態を溶け込ませる取り組みが説明されています。選択性により、18,000 の潜在的なインストールから 18,000 の目に見えるインシデントが発生する可能性が減少しました。

選択された被害者にとって、バックドアは別個のペイロード、認証情報の窃取、横方向への移動、クラウドアクセスのエントリポイントとなる可能性がありました。配布されたインプラントと悪用された組織の区別は不可欠です。影響を受けたパッケージをダウンロードした組織、隔離されたサーバーにインストールした組織、サーバーがビーコンを発信した組織、そして ID が後続のアクセスに使用された組織は、異なる影響カテゴリを占めます。それらを 1 つの数にまとめると、劇的な数字が生まれますが、インシデントモデルとしては不十分です。

攻撃者は 2020 年 6 月、発見の数か月前に SUNBURST を SolarWinds のビルド環境から削除しました。この行為は将来の配布を制限し、本番システムから明白なライブ証拠を除去しました。すでに影響を受けたリリースをインストールした顧客は、インプラントを保持しました。したがって、この作戦はソフトウェア工場における攻撃者の存在よりも長く続きました。生産侵害は数千の独立して展開された成果物に変換され、それぞれが顧客のメンテナンスと保持スケジュールに従いました。

ソースレビューとコード署名だけでは不十分だった理由

Orion インシデントは、しばしば交換可能と見なされるソフトウェア整合性管理策の間のギャップを露呈しました。

ソースレビューは、リリース用にコミットされたコードが受け入れ可能かどうかを問います。ビルド整合性は、コンパイルされた成果物が、承認されたソース、承認された依存関係、承認されたツール、および承認された指示から、侵害されていない環境で実際に生成されたかどうかを問います。署名は、特定の鍵が成果物を承認したかどうかを問います。配布整合性は、顧客が署名された成果物を受け取ったかどうかを問います。実行時管理策は、インストール後に成果物が何を許可されるかを問います。各管理策は、他方が失敗する一方で成功する可能性があります。

Orion において、公開証拠は、永続的なソースリポジトリが SUNBURST の変更を含んでいなかったことを示しています。したがって、コードレビューでは成果物がクリーンであることを証明できませんでした。ビルドシステムは不正なソースを一時的に組み込みました。その後、署名が組織の権限を出力に付与しました。配布は、第三者が変更することなくその出力を配信しました。これらの下流の管理策はそれぞれの狭い役割を果たしましたが、リリースの決定は壊れた上流の事実に基づいていました。

これは、誤った前提に基づいて構築された真実の声明のサプライチェーンバージョンです。パッケージは SolarWinds によって真実に署名されました。顧客が推論したのはより広範なことで、そのパッケージが SolarWinds がリリースを意図した製品を表しているということです。このインシデントはその推論を壊しました。

解決策は署名を放棄することではありません。それらがなければ、顧客はミラーの侵害、ネットワーク傍受、偽造パッケージにもさらされることになります。解決策は署名に付随する証拠を強化することです。高保証のリリースプロセスは、どのソースリビジョン、依存関係セット、ツールチェーン、ビルダーID、ビルドポリシー、テスト、承認が成果物を生み出したかを示すことができるべきです。また、ワーカーが承認されたソース状態に存在しないファイルを置き換えた場合に検出すべきです。同じ ID が独立したチェックなしにソース、ビルドポリシー、成果物、署名決定を変更することを防ぐべきです。

再現可能または独立して繰り返されるビルドは役立ちますが、魔法ではありません。一見独立したビルダーが、認証情報、オーケストレーション、依存関係、または侵害されたコントロールプレーンを共有している場合、同じ悪意のある出力を再現する可能性があります。比較は、信頼パスが真に分離されている場合にのみ意味を持ちます。同様に、ソフトウェア部品表（SBOM）はコンポーネントを特定できますが、ビルドワーカーが追加のファーストパーティコードを挿入したことを示せない場合があります。インベントリは有用ですが、来歴と同等ではありません。

SolarWinds のその後の改善提案は、この問題を認識していました。2021 年 5 月の更新では、3 つの別個のビルド環境、変更されたビルドシステム、独立した認証情報、および出力間の整合性比較が説明されました。議会証言で、CEO の Sudhakar Ramakrishna は、その設計を、攻撃者が複数の異種環境を侵害せざるを得なくする方法として提示しました。同社の書面による上院証言は、当時主張された対応とアーキテクチャの証拠ですが、それ自体はそれ以降のすべてのリリースがその設計を満たしているという独立した認証ではありません。

分母の問題：18,000 は曝露であり、確認された悪用ではない

このインシデントから、18,000 ほど頻繁に繰り返された数字はほとんどありません。それが有用なのは、分母が明示されている場合のみです。

SolarWinds は当初、影響を受けた期間中およびその後にメンテナンス契約が有効だった約 33,000 の Orion 顧客に通知しました。同社は、影響を受けたインストールがあった可能性があるのは 18,000 未満と推定しました。ダウンロードしたがインストールしなかった顧客もいました。コマンド＆コントロールインフラに到達できないシステムにインストールした顧客もいました。インプラントを実行したが後続の活動に選択されなかった顧客もいました。はるかに小規模なグループが後のインフラと通信し、さらに小規模なグループが初期のバックドアを超えて積極的に侵害されました。

2021 年 5 月、SolarWinds は SUNBURST を通じてハッキングされた顧客は 100 未満と推定しました。2021 年 3 月の FBI 証言では、影響を受けた公的および民間の顧客は 16,000 以上、後続の侵害を受けた連邦機関は 9 つ、同じカテゴリの非政府組織は 100 未満と説明されています。「影響を受けた」「インストールされた」「ビーコンを発信した」「標的にされた」「侵害された」が区別されていれば、これらの数字は矛盾しません。

この区別はインシデントを小さくするものではありません。国家主体が選択的に行使した場合でも、何千もの組織に配信された潜在的な管理用の足がかりは深刻なシステム的イベントです。攻撃者は潜在的なアクセスのメニューを取得し、インテリジェンス価値に基づいて標的を選択できました。リスクは、実現された害と信頼された機会の規模の両方にあります。

また、顧客通知にとっても重要です。ベンダーは、すべてのエクスポージャークラスに同じメッセージを送るべきではありません。顧客は、単に成果物をダウンロードしたのか、インストールしたのか、実行したのか、既知のビーコンを生成したのか、コマンド＆コントロール応答を受信したのか、または後続の ID 悪用の証拠を示しているのかを知る必要があります。各状態は、保存、認証情報のリセット、再構築、通知、および継続性の決定を変えます。ベンダー全体のテレメトリが状態を判断できない場合、その不確実性自体が伝達されるべきです。

公開記録はまた、影響をベンダーのテレメトリだけから推測できない理由も示しています。Orion は顧客ネットワーク内で実行されていたため、SolarWinds はすべてのインストールを直接調査することができませんでした。顧客とクラウドプロバイダが証拠の一部を保持していました。一部の後続の活動は SUNBURST を放棄し、正規の認証情報や偽造された認証アサーションを使用したため、クリーンな Orion サーバーは広範な環境がクリーンであることの不十分な証拠にすぎませんでした。インシデントの会計は、ベンダーのダウンロード記録、DNS 観測、ホストフォレンジック、ID ログ、および影響を受けた組織の調査を組み合わせる必要がありました。

発見と遅れた可視性のコスト

FireEye による発見は、しばしば検出の成功として称賛され、実際にそうでした。それはまた、それ以前の安全システムが失敗した証拠でもあります。

数か月間、影響を受けたリリースは信頼されたメンテナンスチャネルを通じて移動しました。攻撃者はインプラントをスリープさせ、分析環境を回避し、使い慣れたプロセスコンテキストを使用し、正規のネットワーク動作を模倣するように設計しました。従来のアンチウイルスと境界ルールは、製品自身のテレメトリに似た活動を実行するベンダー署名付きコンポーネントを認識するのに適していませんでした。ネットワーク管理製品はまた、本来的に広範な動作エンベロープを持っています。システムをインベントリし、セグメント間で通信し、有用な認証情報を保持し、ベンダーインフラストラクチャと正規に接触する場合があります。悪意のある動作は、製品が必要とする特権の内部に隠れることができます。

最初の公的な CISA の対応は、その曖昧さの深刻さを反映していました。CISA の12 月 13 日のアラートは、影響を受けるバージョンを特定し、緊急指令 21-01 は、対象となる Orion 製品を切断するよう連邦政府の民間機関に命じました。この命令は単に「パッチをインストールせよ」ではありませんでした。すでに侵害された管理サーバーには、元の DLL を超えた証拠、認証情報、または永続性が含まれている可能性がありました。それを通常の脆弱性として扱うと、最初のファイルを置き換えた後も攻撃者を保持するリスクがありました。

CISA のその後の排除ガイダンスは、攻撃者が Active Directory や Microsoft 365 に移動した可能性のあるネットワークを対象としていました。排除には、調整された ID 回復、トークンと認証情報の無効化、クラウドレビュー、ホストの再構築、および監視が必要になる可能性があります。これらの手順は、公共サービスがオンラインのままでも運用を中断し、限られた人員を消費する可能性があります。機密侵害の継続性コストは、正当な信頼を回復するために必要な作業によって部分的に測定されます。

英国のNCSC ガイダンスも同様に、影響を受けるバイナリと深刻な後続の影響を区別しました。隔離、ハッシュと DNS チェック、認証情報のリセット、Orion サーバーに関連付けられたアカウントの調査、および完全な再構築の検討を推奨しました。このアドバイスの世界的な一貫性は、信頼の失敗が 1 つの政府の調達環境に限定されていなかったことを示しています。

検出責任は分散されていました。SolarWinds は、ビルドワーカーを監視し、成果物を承認されたソースと比較し、署名を監督し、予期しないリリースの来歴を特定するのに最適な立場にありました。顧客は、Orion の特権を制限し、そのホストをセグメント化し、DNS と ID ログを保存し、自らの環境から逸脱した動作に気付くのに最適な立場にありました。クラウド ID プロバイダーは、テナント間での異常なトークンやアカウントの使用を検出できました。政府の調整機関は、レポートを集約し、強制的な措置を発令できました。単一の観測者が全体像を把握することはできなかったため、タイムリーな情報共有は礼儀ではなく機能的な管理策となりました。

また、この対応はインジケーターに関する厳しい真実を示しています。ハッシュとドメインはトリアージ時に価値がありますが、忍耐強い攻撃者はインフラをローテーションし、有効なアカウントに移動できます。侵入が ID システムにまで達した場合、既知のインジケーターがないことは不在の証明にはなりません。持続的な対応には、攻撃経路を再構築し、既知の良好な状態から信頼を再確立する必要がありました。

目に見えるブラックアウトのない公共セクターの継続性

GAO は、このキャンペーンを連邦政府および民間セクターに対して行われた最も広範で高度なハッキング作戦の 1 つと表現しました。GAO の2022 年の連邦対応レビューでは、各機関がサイバー統合調整グループ（UCG）を結成し、技術的ガイダンスとツールを開発し、情報を共有し、調整、情報アクセス、インシデント対応に関する教訓を特定したことが確認されました。この対応が大規模だったのは、この侵害が政府が自らのシステムを理解し管理するための機構に触れたからです。

9 つの連邦機関が後続の侵害を受けたと公的に特定されました。司法省（DOJ）は、悪意のある活動がその Microsoft 365 のメール環境に到達し、約 3%のメールボックスがアクセスされた可能性がある一方で、機密システムが影響を受けた兆候はないと発表しました。DOJ の2021 年 1 月の声明は、既知の影響を適切に限定しました。同省は、非機密メールの露出を無害とは見なさず、証拠のないシステムの侵害を主張しませんでした。

この状況では、継続性にはいくつかの層があります。

第一は、運用上の可用性です。各機関は、管理サーバーを隔離し、ホストを再構築し、認証情報をローテーションし、クラウドアカウントを調査しながら、公共機能の提供を継続しなければなりません。緊急指令は技術的に必要であると同時に、運用上は混乱を招く可能性があります。

第二は、機密性の継続性です。当局者は、政策草案、調達情報、法務戦略、スケジュール、または連絡網が観察されたかどうかを知る必要があります。諜報キャンペーンは、ファイルを変更または破壊することなく、持続的な優位性を引き出すことができます。

第三は、管理上の整合性です。Orion のネットワーク監視と管理における役割は、顧客が信頼を支えることを意図したツールによって提供される情報を疑わなければならなかったことを意味します。侵害された管理プレーンは、活動を隠蔽したり、認証情報を露出させたり、調査に使用するシステムについてオペレーターを不確かにする可能性があります。

第四は、ID の継続性です。NSA の 2020 年 12 月の認証メカニズムに関する勧告は、特権的なオンプレミスアクセスがどのようにして偽造されたフェデレーション認証とクラウドアクセスにつながるかを説明しました。ローカル ID の信頼が操作されると、最初の Orion ホストを単にクリーンにするだけでは、そこから派生したすべてのセッションやトークンの有効性は回復しません。

第五は、証拠の継続性です。各機関は、ダウンロードされたアップデートがビーコンになったのか、完全な侵害になったのかを判断するために、DNS、エンドポイント、ID、クラウド、管理ログが保持されている必要があります。それらの記録が期限切れになっている場合、指導者はより広範な不確実性の下で行動しなければならず、より広範な修復が必要になる可能性があります。

第六は、制度的な信頼です。政府の購入者は、機密性の高い公共業務のために共有の商用テクノロジーを従業員に使用するよう求めます。このモデルは、ベンダーがセキュリティ慣行を正確に説明し、適切な精度でインシデントを開示し、対応を裏付けるのに十分な証拠を提供することに依存しています。バックドアを運ぶ署名されたアップデートは、パッチ適用プログラムが依存する社会的および管理的な前提を弱体化させます。

このキャンペーンは、自動更新が本質的に安全でないことを示したわけではありません。真正なセキュリティ修正を遅らせる方がはるかに危険な場合があります。これは、アップデート保証にプロデューサーの開発環境とビルド環境を含める必要があることを示しました。ソフトウェア工場を通常の企業ネットワークとして扱いながら、顧客に迅速なパッチ適用を指示することは矛盾を生みます。顧客がアップデートの受け入れに安全になるほど、侵害されたプロデューサーが得る影響力は大きくなります。

SolarWinds の責任：工場に対する管理

SolarWinds は、意図的な国家活動の被害者でした。また、配布メカニズムを可能にした管理上の立場を占めてもいました。

同社は、ソフトウェア開発システム、ビルドワーカー、リリースオーケストレーション、成果物検証、署名経路、および顧客アップデートチャネルへのアクセスを管理していました。顧客は、SolarWinds のビルダー内部にエンドポイント監視を展開することも、署名前の成果物を同社の承認されたソースと比較することも、2 回目の内部ビルドを要求することも、ベンダーの署名鍵が侵害された出力を承認するのを止めることもできませんでした。これらはプロデューサー管理策でした。

運用上の説明責任は、その管理に従います。関連する問題は、いかなる合理的な企業も SVR からの免疫を保証できるかどうかではありません。いかなるプロデューサーもそれを約束することはできません。問題は、リリースプロセスに、侵害された 1 つの環境が署名された製品を静かに変更するのを防ぐことができる、または広範な配布前にその変更を検出できる独立した管理策が含まれていたかどうかです。

2019 年 10 月のテストとその後の SUNSPOT 作戦は、攻撃者がリリースを停止させるような不一致を生じさせることなくビルドを変更する余地を見つけたことを示しています。長期間にわたる内部アクセスと、本番操作の検出の失敗は、管理評価における不利な事実です。攻撃者の高度さは、必要とされる抵抗のレベルに関連しますが、免除にはなりません。製品が政府や主要企業で特権的な地位を占めるベンダーは、有能な攻撃者に標的にされることを予期し、それに応じて工場を設計すべきです。

責任には、インシデントコミュニケーションも含まれます。SolarWinds は顧客に通知し、捜査機関と協力し、SUNSPOT に関する技術情報を公開し、修復策を提供し、一部の顧客サポートに資金を提供しました。これらの行動は被害を軽減し、業界にとって非常に有用な証拠を提供しました。それらは記録に含めるべきです。説明責任とは、永続的に非難されるラベルを探すことではなく、失敗した管理策と対応の質の両方を含みます。

同社の開示は、いくつかの重要な点で慎重でした。SolarWinds は、政府の特定の前に独自に攻撃者の特定を行いませんでした。潜在的なインストールと確認された後続の悪用を区別しました。最初のアクセス経路が未解決のままであることを認めました。提出書類では、訴訟、調査、コスト、顧客、風評リスクを認識していました。これらは意味のある強みですが、後の執行訴訟では同社の以前の公的なセキュリティ表明の側面に異議が唱えられました。

プロデューサーの義務は、修正されたバイナリを出荷して終わりではありません。SolarWinds は、ビルドパス自体が変更されたこと、署名権限が説明のつかない成果物を承認できないこと、認証情報とサードパーティアクセスが制限されていること、そして証拠が忍耐強い侵入を調査するのに十分な期間持続することを証明する必要がありました。主張された 3 ビルドアーキテクチャは、このメカニズムに対応するものでした。持続的な保証には、分離が実際の運用上のプレッシャーに耐えられるかどうかの独立したテストが必要です。

顧客の責任：信頼された製品を制約する

顧客は SolarWinds のビルドシステムを管理していませんでしたが、Orion がインストールされた環境を管理していました。彼らの責任は、製品がその環境に入ったところから始まります。

ネットワーク管理ソフトウェアは、広範なアクセスが便利であるという理由だけで無制限の信頼を受けるべきではありません。顧客は、管理サーバーを隔離し、アウトバウンドのインターネットアクセスを制限し、サービスアカウントを分離し、常駐特権を最小化し、管理認証情報を保護し、製品のネットワーク動作を監視し、監視対象システムの外部にログを保持することができます。NCSC は、外部インフラストラクチャを解決または到達できない影響を受けたサーバーが、初期バックドアの進行を阻止できる可能性があると指摘しました。これは、顧客側の防御がプロバイダー起因の失敗を制限する具体的な例です。

顧客はまた、クラウドとオンプレミスの ID 信頼が、1 つの侵害された管理ホストをより広範な認証機関にすることを許すかどうかも管理していました。分離された管理ワークステーション、階層化された ID、フィッシング耐性のある多要素認証、制約されたフェデレーション、トークン監視、復旧計画は、後続の到達範囲を縮小できます。これらの管理策は、配信された DLL を無害にすることはできませんが、それを実行した結果を変えることができます。

調達およびアーキテクチャチームには別の義務がありました。それは、Orion を影響度の高い依存関係として分類することです。ネットワークトポロジを把握し、管理認証情報を扱い、または重要な資産を監視するツールは、通常のデスクトップユーティリティとは異なる方法で評価されるべきです。購入者は、どの製品が自己更新できるか、どの署名ルートを信頼しているか、リリース成果物がどこから来るか、そして運用上の可視性を失うことなく製品をどれだけ迅速に隔離または交換できるかを知る必要があります。

顧客の責任は依然として実行可能性によって制限されなければなりません。2020 年当時、顧客は署名されたインストーラーから SolarWinds のプライベートなビルドの来歴を再構築することはできませんでした。ほとんどの購入者は、生産パイプラインを監査する契約上の権利や技術的アクセスを欠いていました。優れたセグメンテーションでさえ、署名されたコンポーネントが承認された内部ソース状態と一致するかどうかを知ることはできません。共有責任は、顧客に行使できない管理策を割り当てるときに回避的になります。

したがって、適切な結論は、顧客が無力だったとか、アップデートを信頼したことで侵害を引き起こしたということではありません。署名されたベンダーアップデートを適用することは、一般に期待されるセキュリティ動作です。顧客は、信頼されたコンポーネントの爆発範囲を制限し、独立した検出を維持する責任があります。SolarWinds は、承認し配布した製品の整合性に責任があります。これらの責任は、交換可能になることなく、リスク軽減において重複しています。

政府の責任：購入者、調整者、継続性の所有者

連邦政府は単なる被害者ではありませんでした。主要な購入者であり、規制当局および標準設定者であり、諜報情報の保有者であり、公共の使命に最終的に責任を負う運用者でした。

SolarWinds の前から、連邦サプライチェーンリスク管理はすでに不完全でした。GAO の2021 年 5 月の証言では、レビューされた 23 の文民機関のいずれも、選択された基盤的な情報通信技術サプライチェーン慣行を完全に実装していなかったと指摘されました。このタイミングが重要です。政府は、機関が依存する重要なソフトウェアのインベントリ、評価、および継続的な管理を行わずに、すべての負担をベンダーに合理的に負わせることはできません。

各機関は、製品の配置、サービスアカウントの特権、ネットワーク出力、ID アーキテクチャ、ログ記録、調達要件、および復旧能力を管理していました。CISA の緊急指示が必要だった理由の一部は、影響を受けた機関が一貫して迅速に行動しなければならなかったためです。成熟した継続性計画は、Orion がどこにインストールされているか、何に到達できるか、どの認証情報を使用しているか、切断されたときにどのような運用上の可視性が失われるか、そしてその機能を一時的にどのように置き換えるかをすでに把握しているべきです。

政府はまた、1 つの顧客では得られない集約的な利点を持っていました。CISA、FBI、NSA、ODNI、およびセクターパートナーは、機密情報と非機密情報を組み合わせ、レポートを相互に関連付け、インジケーターを公開し、排除を調整することができました。GAO は、サイバー統合調整グループが対応の組織化に役立った一方で、情報共有と民間セクターのアクセスに関する課題も特定したと指摘しました。調整の遅延は、影響を受けるすべての組織が同じ署名付きファイルが危険かどうかを個別に判断しようとしているときに、公共のコストを生みます。

調達は、政府の最も強力な予防手段の 1 つです。購入者は、安全な開発の証明、インシデント通知条件、成果物の来歴、脆弱性の開示、証拠の保持、対応時の協力、および独立した保証を得る権利を要求できます。また、ビルドがレビューされたソースから逸脱する可能性があるかどうかをテストせずに、サプライヤーが安全な開発ライフサイクルを持っているかどうかを尋ねるチェックボックスコンプライアンスを回避することもできます。

インシデント後の政策記録は、その方向に進みました。NIST のセキュアソフトウェア開発フレームワーク（SSDF）には、開発環境の保護、来歴の保存、リリースの検証、脆弱性への対応、再発防止の実践が含まれています。NIST のサイバーセキュリティサプライチェーンガイダンスは、サプライヤーリスクを調達アンケートに任せるのではなく、エンタープライズガバナンスの中に位置付けています。OMB のM-22-18 覚書は、対象ソフトウェアについて、NIST のセキュア開発慣行に結びついたソフトウェアプロデューサーの証明を連邦機関が取得することを要求しました。

証明は、真実であり、範囲が定められ、テスト可能である場合にのみ有用です。署名された宣言は、基礎となる生産証拠が利用できない場合、署名されたバイナリと同じ認識論的問題を解決できません。影響度の高い購入者は、成果物、例外、独立した評価、是正計画を要求する能力を必要としています。誤った保証は、主張を検証する方法を提供せずに迅速な信頼を促すことで、リスクを高める可能性があります。

法的記録は単純な評決を提供しない

運用上の説明責任と法的責任は、インシデント後に大きく分岐しました。

2023 年 10 月、SEC は SolarWinds Corporation と最高情報セキュリティ責任者の Timothy Brown 氏を詐欺および内部統制違反で告発しました。SEC の訴訟リリースは、SUNBURST 以前の公的声明がセキュリティ慣行を誇張し、既知のリスクを過小報告していたと主張しました。これらの主張は重要でしたが、訴状は当事者の主張であり、事実認定ではありません。

2024 年 7 月、米国ニューヨーク州南部地区連邦地方裁判所はSEC の請求のほとんどを却下しました。裁判所は、SUNBURST 以前の同社のウェブサイトのセキュリティステートメントに基づく証券詐欺の請求を進行させ、修正訴状がアクセス制御とパスワード慣行に関する誤解を招く主張を適切に申し立てていると判断しました。一方、リスク開示、2020 年 12 月の Form 8-Ks、インシデント後の声明、内部会計統制、および開示統制に基づく請求は却下しました。この決定は、訴答および証券法の基準を適用したものであり、SUNBURST の技術的原因に関する審理を行ったり、ビルドプロセスが安全であると宣言したりしたわけではありません。

2025 年 11 月 20 日、SEC と被告は権利放棄付きの却下に合意しました。同庁の最終訴訟リリースは、この決定は裁量の行使であり、必ずしも他の事件における同庁の立場を反映するものではないと述べました。権利放棄付きの却下により、その執行措置は終了しました。これは、生き残った主張が最終的な責任判決にならなかったことを意味します。

この一連の流れは、4 つの規律ある結論を支持します。

第一に、SEC の当初の理論は、確立された事実として繰り返されるべきではありません。多くの請求が却下され、いずれも裁判判決には至りませんでした。

第二に、執行事件の却下は、SolarWinds のビルド管理が 2019 年と 2020 年に適切な基準を満たしていたという技術的証明として提示されるべきではありません。この事件は、特定の声明、要素、法令、および訴答規則に関するものでした。裁判所は、工学管理の失敗が文書化されたままでも、証券請求を棄却することができます。

第三に、却下前に生き残ったウェブサイト声明の請求は、自発的なセキュリティ表明が、広範で内部状況と調和させることが難しい場合に、説明責任のリスクを生み出す可能性があることを示しています。ベンダーは、一般化されたセキュリティ態勢を約束するのではなく、成果、範囲、例外、保証の証拠を正確に記述すべきです。

第四に、法的な不確実性は管理能力の分析を妨げません。SolarWinds は工場を管理し、顧客は展開境界を管理し、政府は公共調達と調整を管理し、SVR は敵対的なキャンペーンを管理しました。契約、損害、因果関係、裁判管轄、および法定義務が、その運用上の地図が法的救済になるかどうかを決定します。ここで使用された情報源のいずれも、これらの当事者間の法的責任の割合を割り当てることを支持しません。

このエピソードは、政策上の緊張も明らかにしました。積極的な執行は、企業が既知のインシデントを過小評価する場合に率直さを改善する可能性がありますが、セキュリティスタッフが、すべての予備的な懸念が後に詐欺として申し立てられると考えるならば、内部文書化や自発的な脅威共有を妨げる可能性もあります。より良い説明責任体制は、適切な基準の下で証明された実質的に虚偽の主張を罰する一方で、迅速で確信度ラベル付きの開示を報奨します。被害者として扱われる代償として完全な予防を要求すべきではありません。

修復は証拠を変えなければならない、アーキテクチャ図だけではない

SolarWinds は、発見後に広範な変更を報告しました。より広範な多要素認証、より厳格な最小特権、サードパーティアプリケーションのより強力なレビュー、強化された監視、再設計されたビルドプロセス、複数の分離されたビルダー、別個の認証情報、出力比較、静的解析、オープンソース解析、ペネトレーションテスト、および資産追跡です。SUNSPOT の詳細を公開したことで、他のプロデューサーに具体的な脅威モデルを提供しました。これらは関連性があり、メカニズムに特化した対応です。

最も強力な修復の主張は、「現在 3 か所でビルドしています」ではありません。それは、不正な一時的なソース変更が、検出可能な不一致を生じさせることなく署名されたリリースに到達できないことを示す一連の証拠です。その証拠は、担当者の変更、期限のプレッシャー、緊急パッチ、ビルダーの交換があっても維持されるべきです。

信頼できる保証パッケージは、少なくとも以下の質問に答えるでしょう。

リリースされたすべてのバイナリは、不変の承認されたソースリビジョン、依存関係セット、コンパイラ、ビルドポリシーまで追跡できますか？
ビルドワーカーはエフェメラルですか、それとも検証済みの状態から復元されますか？また、そのコントロールプレーンは通常の企業 ID から分離されていますか？
1 つの認証情報で、ビルドを変更し、テレメトリを抑制し、本番署名を要求できますか？
個別のビルドは真に独立していますか、それとも同一の侵害を生み出せる隠れた依存関係を共有していますか？
署名サービスは来歴とポリシーを検証しますか、それとも承認されたアカウントから提示されたあらゆる成果物に署名しますか？
ビルドおよび署名ログは、別途管理された改ざん耐性のあるストアに書き込まれ、国家主体から予想される滞在期間にわたって保持されますか？
テストカナリアや制御された故障注入を使用して、不正なビルドのばらつきがリリースを停止させることを証明していますか？
ベンダーは、リリースを取り消し、エクスポージャークラスごとに顧客に通知し、フォレンジック証拠を破壊することなくクリーンな復旧成果物を提供できますか？
顧客は検証可能な来歴を受け取りますか、それとも署名とマーケティング保証だけですか？
リスクが変化するリーダーシップや顧客に例外が見えるようになっていますか？

これらは、すべての購入者にソースコードや機密の生産秘密の開示を要求するものではありません。独立した監査人、政府の評価者、管理された透明性メカニズムは、攻撃マップを公開することなく成果を検証できます。目的は、製品の特権とシステム的な到達範囲に見合った証拠です。

顧客は補完的な証明を必要とします。Orion または同等の管理プラットフォームがすべての管理層に自由に到達できないこと、サービスアカウントの範囲が制限されていること、アウトバウンドトラフィックが実用的な場合に許可リスト化されていること、ID と DNS のログが管理対象環境の外に残されること、侵害された管理サーバーをすべての運用認識を失うことなく隔離できること、そしてクラウドフェデレーションを既知の良好な権限から再構築できることを示せるべきです。

政府の購入者は、書類を受け取るだけでなく、継続性をテストするべきです。机上演習では、数時間以内にネットワーク管理プラットフォームを切断し、関連する認証情報を列挙し、証拠を保存し、代替ツールで可視性を復元し、ID リセットを調整するよう機関に求めることができます。その演習での失敗は、実際の指令が届く前に公共のリスクを特定します。

説明責任の実践的な配分

このインシデントは、見出しへの近さではなく、管理能力によって責任を割り当てると、より明確になります。

米国および同盟国による特定によれば、ロシア対外情報庁（SVR）がこの諜報キャペーンを計画し実行しました。SVR はサプライヤーを侵害することを選択し、SUNSPOT と SUNBURST を設計し、下流の標的を選定し、盗んだアクセスを使用しました。その非難可能性は一次的かつ意図的です。

SolarWinds は、内部アクセスアーキテクチャが攻撃者を制限するかどうか、ビルド出力が承認されたソースに対応しなければならないかどうか、ビルダーと署名が独立して監督されるかどうか、異常なリリース動作がアラートを生成するかどうか、顧客が正確でタイムリーな証拠を受け取るかどうかを管理していました。同社はまた、修復と開示の重要な部分を管理していました。被害者としての地位がこれらの責任を取り除くわけではなく、後の透明性が最初の失敗を消すわけではありませんが、将来の害を減らすことはできます。

顧客は、製品の配置、特権、ネットワーク経路、ログ保持、インシデントエスカレーション、および ID 回復を管理していました。Orion に無制限の管理到達範囲を与え、脆弱な外部監視を行っていた組織は、プラットフォームを隔離していた組織よりも大きな結果を受け入れました。その違いは、どちらの顧客も悪意のあるリリースを引き起こしたわけではないにもかかわらず、予防可能性と損害に影響を与えます。

クラウドおよび ID プロバイダーは、テナント間のテレメトリと、偽造または悪用された認証を検出または無効化するメカニズムを管理していました。後続のクラウドアクセスは、ソフトウェアサプライチェーンインシデントをより広範な ID インシデントに変えました。したがって、プロバイダーの協力とログは信頼回復の一部でした。

連邦機関のリーダーは、ミッション継続性、インベントリ、調達条件、および政府全体のサプライチェーン慣行の実施を管理していました。CISA とパートナー機関は、調整されたアラート、指令、ツール、および共有されたインシデント理解を管理していました。議会と規制当局は、法定権限の範囲内で、監視とインセンティブを管理していました。

ソフトウェアプロデューサーの経営陣と取締役会は、ビルドセキュリティが製品要件なのか、ベストエフォートの内部プロジェクトなのかを決定するリソースとインセンティブを管理しています。管理到達範囲を持つソフトウェアのビルドパイプラインは、製品の安全境界の一部です。それに関する投資決定は、出荷されるコードに関する決定と同様に統治されるべきです。

いかなる当事者の責任も、他方の責任を打ち消すことはありません。「顧客は Orion をセグメント化すべきだった」という言葉は、なぜ不正な成果物が署名されたのかに答えません。「SolarWinds はビルドを保護すべきだった」という言葉は、なぜ管理サーバーが顧客の最も重要な ID に到達できたのかに答えません。「SVR は高度だった」という言葉は、独立したビルド検証が存在したかどうかに答えません。成熟した説明は、3 つの発言すべてを真実としながら、各当事者が今何を証明しなければならないかを問い続けます。

永続的な教訓：署名には生産の真実のチェーンが必要

SolarWinds の侵害は、ソフトウェアサプライチェーン政策を変えました。なぜなら、それが本来望ましい習慣、つまりベンダーからアップデートを入手し、署名を検証し、迅速に適用するという習慣を悪用したからです。この事象はその習慣を不合理にしたわけではありません。それは、顧客の信頼が生産プロセスによって公開される証拠を上回っていたことを示しました。

是正モデルは、生産の真実のチェーンです。承認されたソースは、特定されたビルド要求につながるべきです。その要求は、堅牢で観察可能な環境で実行されるべきです。依存関係とツールは固定され記録されるべきです。結果の成果物は、独立した期待値と比較されるべきです。署名は、ポリシーと来歴のチェック後にのみ行われるべきです。配布は成果物を保存すべきです。顧客は、署名鍵の所有以上のことを検証できるべきです。ログは、長い滞在期間の後でもすべてのリンクを調査可能にするべきです。

そのモデルはまた、公共の継続性を改善します。リリースが疑問視された場合、各機関はどの成果物を実行したか、どのソースとビルダーがそれを生成したか、それがどのような特権を持っていたか、何に接触したか、どの ID を回復する必要があるかを判断できます。不確実性は狭まります。対応は無差別ではなく標的化されます。重要なサービスは、クリーンであることが証明できるシステムの再構築に費やす時間を減らし、そうでないシステムにより多くの時間を費やします。

SolarWinds は、ハッキングされた企業としてだけ、または無制限のベンダー責任を要求するために使われるシンボルとしてだけ記憶されるべきではありません。より有用な教訓は制度的なものです。ソフトウェアプロデューサーは、オンプレミス製品を販売している場合でも、顧客にとってインフラストラクチャになることができます。そのビルドシステムは、顧客がそれを見ることがなくても公共の信頼境界になることができます。そして、暗号署名は完全に有効でありながら、人々がそれに付随する組織的な主張が誤っている可能性があります。

説明責任の基準は、その現実から導かれるべきです。攻撃者は侵入に責任があります。ベンダーは、リリース経路を耐性があり、観察可能で、正直に記述する責任があります。顧客は、製品を封じ込め、独立した証拠を保存する責任があります。政府は、それらの依存関係を考慮して購入し、信頼が崩壊したときに公共の使命を維持する責任があります。2020 年の Orion キャンペーンは、これら 4 つの領域すべてにまたがりました。持続可能な修復も同様でなければなりません。