matsumokei / System_article

0 stars 0 forks source link

SoK: Analysis of Software Supply Chain Security by Establishing Secure Design Properties #15

Open matsumokei opened 4 months ago

matsumokei commented 4 months ago

k

matsumokei commented 4 months ago

産業、政府、および学術のコンピューティング・システムは、オープン・ソースとクローズド・ソースのソフトウェア・コンポーネントのサプライ・チェーンに依存している [60]。この連鎖のどの段階を支配する行為者も、偶発的に、または悪意を持って、下流のソフトウェアを妨害する可能性がある[59, 63]。ソフトウェア・サプライ・チェーンにおける問題は、サイトやインターネット全体の混乱を引き起こし、そのコストは数十億ドルにのぼると推定されている[12, 57]。これらの問題には、サービスの停止 [15, 20] や、人命 [25] や国家安全保障 [24] を脅かすサイバーセキュリティの悪用が含まれる。ソフトウェア・サプライ・チェーンの悪用は、要件の不一致に起因する可能性がある。多くのソフトウェア・サプライ・チェーンは、もともと共有のために設計されたものであり、サイバーセキュリティのために設計されたものではない。セキュリティに対する新たな要求を考慮すると、サプライチェーンはどのように設計されるべきなのだろうか?研究者たちは、現在のソフトウェア・サプライ・チェーンがどのように攻撃され得るかについての知識を構造化することから始めている。例えば、攻撃の分類法は、攻撃者がどのようにサプライチェーンを侵害するかを理解するのに役立つ攻撃ツリーを生み出す。また、エコシステム分析は、外部依存関係を選択する際に、ソフトウェア依存関係の構造がどのように脆弱性を高めたり低めたりするかを理解するのに役立っている [19, 80, 81]。産業界や学界におけるデータ科学に基づく取り組みでは、侵害のシグナルや指標を特定することが試みられている [79]。他の研究者は、ソフトウエアのサプライチェーンのセキュリ ティを向上させるための設計変更について調査している。このような洞察に基づき、これらの攻撃ベクトルを軽減するためのシス テムやメカニズムの開発に重点が置かれている。in-toto」や「Sigstore」のような取り組みは、ソフトウェア・サプライ・チェーンにおける現在の運用に、セキュリティの層を提供しようとするものである。これらは一般に、ソフトウェア・サプライ・チェーンにおける一群の攻撃から保護することを目的としている。例えば、Solarwind社のTrebuchetプロジェクト[24]は、intotoで調整された再現可能なビルドベースのパイプラインによって、コンパイル済みのバックドアを防ぐことを目的としている。このことは、ソフトウェアサプライチェーン攻撃に対する強固なセキュリティ体制を提供するために使用できるメカニズムや構成の組み合わせを記述する「メタフレームワーク」や「ベストプラクティスモデル」の開発につながっています。このようなアプローチの例としては、Cloud Native Computing Foundations Technical Advisory Group on Security(CNCFのTAG-Security)によるセキュアソフトウェアパイプラインのリファレンスアーキテクチャ[31]や、Secure Software Factory(セキュアソフトウェアファクトリー)[32]がある。この分野の新たな性質とばらばらの取り組みの多さを考慮すると、学術界、産業界、オープンソースの様々なグループが、ソフトウェアサプライチェーンをセキュアにするための複数の参照アーキテクチャとデザインパターンを提案している。しかし、システムインテグレーターや設計者が、これらのメカニズムやさまざまなアーキテクチャがどのように設計され、一般的なソフトウェアパイプラインに適用されているかを理解し、マッチングするのに役立つ体系化されたフレームワークはまだ存在しない。これは、これらの異なるコミュニティ間の断絶によるところもあるが、脅威のカタログ化と、脅威を緩和するためのシステムの組み合わせの適用という、両方の研究目的をマッピングするための構造化されたフレームワークの欠如によるところもある。本稿の目的は、ソフトウェアサプライチェーンにおけるセキュリティのデザインパターンに関する知識を要約することである。安全なサプライチェーンのための現在のデザインパターンを体系的にレビューし、それらのセキュリティの姿勢を比較するためのフレームワークを開発する。そうすることで、産・学・官によって提案されている現在のベストプラクティスに関する初めての包括的な研究を提供する。まず、ソフトウェア・サプライチェーンについて説明する(§2)。次に、ソフトウェアサプライチェーン攻撃に対する 4 段階の攻撃パターンを提示する(§3.1)。次に、ソフトウェアサプライチェーンの安全性を確保するための 3 つの特性(透明性、有効性、分離)を提示する(§3.2)。その後、現在のセキュリティ対策がどのようにセキュリティ原則を満たしているかを文書化し(§4)、いくつかのケーススタディを提供する(§5)。最後に、ソフトウエアサプライチェーンのセキュリ ティをさらに向上させる機会を特定する(§6)。要約すると、我々の貢献は以下のとおりである: (1) ソフトウェア・サプライチェーン攻撃の攻撃パターン(§3.1)。(2) 安全なソフトウェアサプライチェーンのための原則(§3.2)。(3) 現在のセキュリティ対策の収集と分析(§4 と§5)。

matsumokei commented 4 months ago

ソフトウェアのサプライチェーンは、ますます一般的になっている攻撃ベクターである [43]。サプライチェーンは、アーティファクト(成果物)を共有し、オペレーションを実行する、複数の接続されたリンクで構成される。アクターはリンクとコンポーネントを管理する。しかし、ソフトウェアサプライチェーン攻撃と他のソフトウェア攻撃との違いは、文献では明確に定義されていません。Ladisaら[43]とOhmら[57]は、サプライチェーン攻撃を、下流のリンクを標的としたサプライチェーンへの悪意のあるコードの注入と定義しています。ENISA [18]は、サプライチェーン攻撃を、サプライヤに対する攻撃と、それに続く標的に対する攻撃という、少なくとも2つの攻撃の組み合わせとして定義している。Zimmermann ら [81]や Zahan ら [79]のような他の研究は、サプライチェーン攻撃のための厳密なコードインジェクション以外の方法を特定しています。複数の情報源からソフトウェアサプライチェーン攻撃の概念を抽出すると、図 2 に示すような特徴的な 4 段階の攻撃パターンに到達します。(2) 改ざん: (2) 改ざん:攻撃者が最初の侵害を利用して、ソフトウェアのサプライチェーンを改ざんする。(3) 伝播: 第三に、攻撃者によってもたらされた変更が、下流のコンポーネントやリンクに伝播する。(4) 悪用: 最後に、攻撃者は下流のリンクの変更を悪用します。この定義を説明するために、SOLARBURST 妥協 [11, 49] を考えてみましょう。このサプライチェーン攻撃では、攻撃者がビルドプロセス中に悪意のあるコードを注入することで、SolarWinds社の既存のソフトウェアを改ざんしました。この攻撃は、図 2 の 4 段階の攻撃に当てはめると、次のようになります: (1) 既存の弱点はビルドインフラストラクチャである。(2) 改ざんされたのは、コンパイラによって注入された悪意のあるコードで、SolarWinds製品コンポーネントの認証をバイパスすることをユーザーに許可しました。(3)感染経路は、SolarWindsの侵害された製品であり、そのユーザーには多くの企業、IRSやNASAのような米国政府機関が含まれる。(4) 悪用されたのは、壊れた認証メカニズムを利用して、影響を受けたマシンを制御することであった。このようなインシデントは一般的になりつつあり、ソフトウェア・サプライチェーンの侵害は過去3年間で累計650%増加している[66, 68, 69]。このパターンとは対照的に、ロッキード・マーチンのサイバー・キル・チェーン[46]で説明されているような従来の攻撃は、単に既存の脆弱性を悪用するものです(ステップ 4)。ソフトウェアに対する攻撃は、そのソフトウェアがサプライチェーンの中に存在するからといって、必ずしもサプライチェーンに対する攻撃とは限りません。このため、依存関係の脆弱性を利用したソフトウェアへの攻撃は、攻撃パターンに従わない限りサプライチェーン攻撃とは言えません。この攻撃パターンに関する別の視点として、欧州連合サイバーセキュリティ機関(ENISA)[18]および Ohm ら[57]が示した、脆弱な依存関係と悪意のある依存関係の区別を考えてみましょう。サプライチェーンの脆弱なリンクには、さらに下流で悪用される可能性のある意図しない弱点が含まれています。これらの悪用はサプライチェーン攻撃ではない。一方、サプライチェーンの悪意のあるリンクは、サプライチェーンの残りの部分を弱体化させるために意図的に設計されたものである。このような弱点の導入とその後の悪用は、サプライチェーン攻撃を構成する。既存の文献は、既知のサプライチェーン攻撃を分類し、文書化している[18, 43, 57, 81]。個々の攻撃のタイプを列挙することは、本稿の範囲外である。通常、この分野の研究では、攻撃者がどのようにサプライチェーンを侵害し、改ざんするかを区別しています。3.2 ソフトウェアサプライチェーンのセキュリティ特性 脆弱性の存在と攻撃のリスクを軽減するために、サプライチェーンの構成要素は安全でなければならない。攻撃者がコンポーネントを侵害したり、サプライチェーンを改ざんしたり、悪意のある変更を伝播したりすることができなくなれば、サプライチェーンは安全なものとなる。ソフトウェアサプライチェーンのセキュリティに関する文献の中で、私たちは、3つの直交する繰り返し現れるセキュリティ特性を特定しました: 行為者はサプライチェーンの一部しかコントロールできないが、サプライチェーン全体に関する知識が増えることで、すべての当事者がリスクを軽減したり、攻撃に対して特定の対策を講じたりすることができるようになる[13、22、23、43、48]。透明性とは、サプライチェーンの関係者が知識を利用できることを意味する。透明性は、チェーン内のリンクを接続し、構成するエンティティに適用される。妥当性: ソフトウェアサプライチェーンは正しいままでなければならない。単一のリンクにおける行為者、業務、または成果物への変更は、下流のエンティティを危険にさらす可能性がある。妥当性には、操作の完全性、成果物の完全性、および行為者の認証が含まれます。サプライチェーンの各リンクには、チェーン内の他のリンクと相互作用する一連の操作と成果物が含まれています。安全なサプライチェーンは、これらの構成要素が悪意のある当事者によって変更されないことを必要とする[13, 23, 48]。従って、リンクの接続や構成要素に変更を加えることができるのは、許可されたアクターだけであるべきです。また、このような変更は許可を得なければならない[23, 72, 79]。(3) 分離: 安全なサプライチェーンは、区画化された性質を体現している。接続はサプライチェーンに不可欠な要素であるが、必要な場合にのみ存在すべきである。このような接続は、攻撃表面積を減少させるために最小化されるべきである。さらに、論理的に分離された業務、成果物、および行為者は、意図しないつながりを最小限に抑えるために、実際には分離されたままであるべきである。ミラーリング、バージョンロック、コンテナなどの対策を実施することで、個々のコンポー ネントは、他のコンポーネントのセキュリティへの依存を減らすことができる。