概要

  • Orion キャンペーンは、攻撃者がソフトウェア開発プロセスを侵害し、自動ビルド中に SUNBURST を挿入し、SolarWinds の通常の署名・配布機構を利用して改変コンポーネントを配信したことで成功した。有効な署名は侵害されたリリースプロセスを認証したが、結果コードが承認されたソース状態と一致することを独立に証明するものではなかった。
  • 影響を受けたリリースを入手した可能性のある顧客は1万8000未満だが、この数字はフォローオン活動で侵入された組織の数ではない。後の公的推定では、確認または評価されたフォローオン侵害は米国連邦政府機関9機関と非政府組織100未満であり、SolarWinds は別途 SUNBURST による顧客侵害を100未満と推定している。
  • ロシア対外情報庁(SVR)がスパイ活動の責任を負う。しかし SolarWinds はビルド環境、リリース来歴、署名経路、製品アーキテクチャを管理し、内部の1回の侵害を顧客サイトの信頼コードに変えた。顧客と政府購入者はセグメンテーション、ロギング、ID 強化、調達、復旧を管理した。説明責任は各当事者が実際に運用できる保護手段に帰属する。
  • 法的記録は運用記録より狭い。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 のインシデント開示と証券開示、CrowdStrike と Mandiant の技術分析、CISA、NSA、FBI、影響を受けた機関の記録、GAO の連邦対応レビュー、議会証言、後の裁判記録である。すべての疑問に答えるわけではないが、いくつかの中核的事実を確立する。

第一に、高度な攻撃者が SolarWinds 環境に長期間アクセスを維持し、Orion の開発プロセスを研究した。SolarWinds の2021年5月の調査更新は、初期侵入の時期や方法を特定できなかったと述べた。侵害された認証情報と、ソフトウェア開発環境や内部システム(Microsoft 365を含む)への永続的アクセスが、2019年10月のテスト実行の少なくとも9か月前から存在した証拠を報告した。初期経路として、サードパーティのゼロデイ、ブルートフォース(パスワードスプレーなど)、ソーシャルエンジニアリングの可能性を絞り込んだが、証明はしていない。

第二に、敵対的な変更は自動ビルド環境で行われ、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は、該当期間にダウンロード、実装、または更新された製品に脆弱性が含まれ、影響を受けたリリースをインストールした可能性のある顧客は1万8000未満と推定した。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 設定に溶け込ませる努力を説明した。選択性により、1万8000の潜在的なインストールが1万8000の可視インシデントを生む可能性を減らした。

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

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

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

Orion インシデントは、しばしば互換性があると扱われるソフトウェア整合性管理の間のギャップを露呈した。

ソースレビューは、リリース用にコミットされたコードが許容可能かどうかを尋ねる。ビルド整合性は、コンパイルされた成果物が実際に承認されたソース、依存関係、ツール、指示から、侵害されていない環境で生産されたかどうかを尋ねる。署名は特定のキーが成果物を承認したかどうかを尋ねる。配布整合性は、顧客が署名された成果物を受け取ったかどうかを尋ねる。ランタイム制御は、インストール後に成果物が何を許可されるかを尋ねる。各制御は成功する一方で、別の制御が失敗する可能性がある。

Orion では、公的証拠は永続的ソースリポジトリが SUNBURST 改変を運んでいなかったことを示している。したがってコードレビューは成果物がクリーンであることを証明できなかった。ビルドシステムは無許可ソースを一時的に組み込んだ。署名はその後、組織の権限を出力に付与した。配布は第三者による改変なしにその出力を届けた。これらの下流制御はそれぞれの狭い仕事を果たしたが、リリース決定は壊れた上流の事実に基づいていた。

これは、誤った前提に基づく真実の声明のサプライチェーン版である。パッケージは SolarWinds によって真実に署名された。顧客が推測したのはより広範で、パッケージは SolarWinds がリリースしようとした製品を表しているというものだった。インシデントはその推測を破った。

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

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

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

分母問題:1万8000は露出であり、確定した悪用ではない

事件からこれほど繰り返し引用された数字はほとんどない。1万8000は、その分母が述べられる場合にのみ有用である。

SolarWinds は当初、影響を受けた期間中および期間後にアクティブなメンテナンス契約にある約3万3000の Orion 顧客に通知した。影響を受けるインストールがあった可能性があるのは1万8000未満と推定した。ダウンロードしたがインストールしなかったケースもある。C2 インフラに到達できないシステムにインストールしたケースもある。インプラントを実行したがフォローオン活動に選ばれなかったケースもある。よりはるかに少ないグループが後のインフラと通信し、さらに少ないグループが最初のバックドアを超えて積極的に侵害された。

2021年5月、SolarWinds は SUNBURST によってハッキングされた顧客は100未満と推定した。2021年3月、FBI の証言は、1万6000以上の影響を受けた公的・私的顧客、フォローオン侵害を受けた9つの連邦機関、そのカテゴリの非政府組織100未満と説明した。これらの数字は、「影響を受けた」「インストールされた」「ビーコンを発した」「標的にされた」「侵害された」が区別されれば互換性がある。

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

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

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

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

FireEye の発見はしばしば検出の成功として称賛される。確かにそうだった。しかしそれは、初期の安全システムが失敗した証拠でもある。

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

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

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

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

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

対応はまた、指標に関する厳しい真実を示している。ハッシュとドメインはトリアージ中に価値があるが、忍耐強い攻撃者はインフラをローテーションし、有効なアカウントに移行できる。既知の指標の欠如は、侵入が ID システムに及んだ場合、不在の証明ではない。耐久性のある対応は攻撃経路を再構築し、既知の良好な状態から信頼を再確立しなければならなかった。

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

GAO はキャンペーンを、連邦政府と民間部門に対して行われた最も広範で洗練されたハッキング作戦の一つと説明した。その2022年の連邦対応レビューは、機関がサイバー統一調整グループを形成し、技術的ガイダンスとツールを開発し、情報を共有し、調整、情報アクセス、インシデント対応に関する教訓を特定したことを明らかにした。対応が大規模だったのは、侵害が政府が自らのシステムを理解し管理するための機構に触れたからである。

9つの連邦機関がフォローオン侵害を受けたと公に特定された。司法省は悪意活動が Microsoft 365電子メール環境に達し、約3%のメールボックスが潜在的にアクセスされたが、機密システムが影響を受けた兆候はないと述べた。DOJ の2021年1月の声明は既知の影響を適切に限定した。非機密電子メールの露出を無害として扱わず、証拠がないシステムの侵害を主張しなかった。

継続性にはこの設定でいくつかの層がある。

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

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

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

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

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

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

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

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

SolarWinds は意図的な国家作戦の被害者だった。同時に、配布メカニズムを可能にした管理位置を占めていた。

同社はソフトウェア開発システム、ビルドワーカー、リリースオーケストレーション、成果物検証、署名経路、顧客更新チャネルへのアクセスを管理していた。顧客は SolarWinds のビルダー内にエンドポイント監視を展開できなかった。署名前の成果物を会社の承認ソースと比較したり、第二の内部ビルドを要求したり、ベンダーの署名キーが侵害された出力を承認するのを止めたりできなかった。これらはプロデューサーの管理だった。

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

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

責任にはインシデントコミュニケーションも含まれる。SolarWinds は顧客に通知し、調査者と協力し、SUNSPOT に関する技術情報を公開し、是正措置を提供し、一部の顧客サポートに資金を提供した。これらの行動は害を減らし、異常に有用な業界の証拠を提供した。それらは記録にカウントされるべきである。説明責任は永久的に非難されるべきラベルの検索ではなく、失敗した管理と対応の質の両方を含む。

会社の開示はいくつかの重要な点で注意深かった。SolarWinds は政府の帰属前に攻撃者を独立に帰属させなかった。潜在的なインストールと確認されたフォローオン悪用を区別した。初期アクセスが未解決のままであることを認めた。その提出書類は訴訟、調査、コスト、顧客、風評リスクを認識した。これらは意味のある強みであり、後の執行訴訟が会社の以前の公的セキュリティ表明の側面を争ったとしてもである。

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

顧客の責任:信頼された製品の制約

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

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

顧客はまた、クラウドとオンプレミスの ID 信頼が、一つの侵害された管理ホストをより広範な認証権限に変えることを許可するかどうかを管理していた。別個の管理ワークステーション、階層化 ID、フィッシング耐性多要素認証、制約されたフェデレーション、トークン監視、復旧計画がフォローオンリーチを減らす可能性があった。これらの管理は配信された DLL を無害にできなかったが、それを実行した場合の結果を変えることができた。

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

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

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

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

連邦政府は被害者であるだけでなく、主要な購入者、規制当局および標準設定者、インテリジェンス保持者、そして最終的に公共ミッションの運営者でもあった。

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

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

政府はまた、単一の顧客が利用できない総合的な優位性を保持していた。CISA、FBI、NSA、ODNI、セクターパートナーは、分類および非分類情報を組み合わせ、報告を関連付け、指標を公開し、追い出しを調整できた。GAO は、サイバー統一調整グループが対応の整理に役立った一方で、情報共有と民間セクターアクセスに関わる課題も特定した。調整の遅延は、すべての影響を受けた組織が同じ署名ファイルが危険かどうかを別々に判断しようとしている場合、公共のコストが発生する。

調達は政府の最も強力な予防的手段の一つである。購入者は、セキュア開発の証明、インシデント通知条項、成果物来歴、脆弱性開示、証拠保持、対応中の協力、独立した保証を得る権利を要求できる。また、サプライヤーがセキュア開発ライフサイクルを持っているかどうかを尋ねるだけで、ビルドがレビューされたソースから乖離できるかどうかをテストしないチェックボックスコンプライアンスを避けることができる。

インシデント後の政策記録はその方向に動いた。NIST のSecure Software Development Frameworkは、開発環境の保護、来歴の保存、リリース検証、脆弱性対応、再発防止のプラクティスを含む。NIST のサイバーセキュリティサプライチェーンガイダンスは、サプライヤーリスクを調達アンケートに任せるのではなく、企業ガバナンス内に配置する。OMB のM-22-18 覚書は、連邦機関に対象ソフトウェアについて、NIST のセキュア開発プラクティスに基づくソフトウェアプロデューサーの証明を取得することを要求した。

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

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

運用説明責任と法的責任は、インシデント後に大きく乖離した。

2023年10月、SEC は SolarWinds Corporation と最高情報セキュリティ責任者 Timothy Brown を詐欺および管理違反で告発した。SEC 訴訟リリースは、公的声明がセキュリティ慣行を誇張し、SUNBURST 以前に既知のリスクを過小評価していたと主張した。これらの主張は重要だったが、告訴は弁護人の申立であり、事実認定ではない。

2024年7月、ニューヨーク南部地区連邦地方裁判所は SEC のほとんどの主張を却下した。裁判所は、SUNBURST 前の会社のウェブサイト「Security Statement」に基づく証券詐欺の主張を進行させ、修正された告訴がアクセス制御とパスワード慣行に関する誤解を招く主張を適切に主張していると判断した。リスク開示、2020年12月の Form 8-K、インシデント後の声明、内部会計管理、開示管理に基づく主張は却下した。決定は申立と証券法基準を適用した。SUNBURST の技術的原因に関する裁判は行わず、ビルドプロセスが安全であると宣言しなかった。

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

この経緯は4つの規律ある結論を支える。

第一に、SEC の当初の理論は確定した事実として繰り返されるべきではない。多くの主張は却下され、裁判判断は生まれなかった。

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

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

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

エピソードはまた政策の緊張を明らかにした。積極的な執行は、企業が既知のインシデントを最小化する場合に率直さを向上させる可能性がある。また、セキュリティスタッフがすべての予備的懸念が後に詐欺として申し立てられると信じる場合、内部文書化や自発的な脅威共有を抑制する可能性もある。より良い説明責任体制は、自信を持ってラベル付けされた開示を促進し、適切な基準の下で証明された実質的に虚偽の主張を罰する。完全な予防を被害者として扱われるための代償とするべきではない。

是正はアーキテクチャ図だけでなく証拠を変えなければならない

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

最も強力な是正主張は「現在は3か所でビルドしている」ではない。それは、許可されていない一時的なソース変更が、検出可能な不一致を生じさせることなく署名リリースに到達できないことを示す一連の証拠である。その証拠は、人事異動、納期圧力、緊急パッチ、ビルダー交換を生き残るべきである。

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

  1. すべてのリリースバイナリを、不変の承認済みソースリビジョン、依存関係セット、コンパイラ、ビルドポリシーに遡って追跡できるか?
  2. ビルドワーカーは一時的であるか、検証された状態から復元されるか、そのコントロールプレーンは通常の企業 ID から分離されているか?
  3. 単一の認証情報でビルドを変更し、テレメトリを抑制し、本番署名を要求できるか?
  4. 別々のビルドは本当に独立しているか、それとも同一の侵害を生み出す隠れた依存関係を共有しているか?
  5. 署名サービスは来歴とポリシーを検証するか、それとも承認されたアカウントが提示した任意の成果物に署名するか?
  6. ビルドと署名のログは、別途管理され、耐タンパー性のあるストアに書き込まれ、国家アクターに期待される滞留時間の間保持されるか?
  7. 許可されていないビルドのバリエーションがリリースを停止することを証明するために、テストカナリアや制御されたフォールトインジェクションが使用されているか?
  8. ベンダーはリリースを撤回し、露出クラスごとに顧客に通知し、フォレンジック証拠を破壊せずにクリーンな復旧成果物を提供できるか?
  9. 顧客は検証可能な来歴を受け取るか、それとも署名とマーケティング保証のみか?
  10. 例外は、リスクがそれによって変化するリーダーシップと顧客に見えるか?

これらは、ソースコードや機密の生産秘密をすべての購入者に開示するよう要求するものではない。独立した監査人、政府評価者、管理された透明性メカニズムは、攻撃マップを公開せずに結果を検証できる。目的は、製品の特権とシステム上のリーチに比例した証拠である。

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

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

説明責任の実践的な配分

インシデントは、見出しへの近接性ではなく、管理能力によって責任が割り当てられるときに明確になる。

米国および同盟国の帰属によれば、ロシア SVR はスパイ活動キャンペーンを計画し実行した。サプライヤーを侵害し、SUNSPOT と SUNBURST を設計し、下流の標的を選択し、盗んだアクセスを使用することを選択した。その罪責は一次的かつ意図的である。

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

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

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

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

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

いずれの当事者の責任も他方をキャンセルしない。「顧客は Orion をセグメント化すべきだった」では、なぜ許可されていない成果物が署名されたのかという問いに答えない。「SolarWinds はビルドを保護すべきだった」では、なぜ管理サーバが顧客の最高価値 ID に到達できたのかという問いに答えない。「SVR は洗練されていた」では、独立したビルド検証が存在したのかという問いに答えない。成熟した説明では、3つの声明すべてが真実であり得、なお各当事者が今何を証明しなければならないかを問う。

永続的な教訓:署名には生産真実の連鎖が必要

SolarWinds 侵害は、そうでなければ望ましい習慣、つまりベンダーからアップデートを取得し、署名を検証し、迅速に適用するという習慣を悪用したため、ソフトウェアサプライチェーン政策を変えた。イベントはその習慣を非合理的にしなかった。それは、顧客の信頼が生産プロセスによって露出された証拠を追い越していたことを示した。

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

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

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

説明責任基準はその現実に従うべきである。攻撃者は侵入に責任がある。ベンダーはリリースパスを耐性があり、観測可能で、正直に説明されるようにする責任がある。顧客は製品を封じ込め、独立した証拠を保存する責任がある。政府はそれらの依存関係を視野に入れて購入し、信頼が崩壊したときに公共ミッションを維持する責任がある。2020年の Orion キャンペーンは4つの領域すべてにまたがった。耐久性のある是正も同様でなければならない。