サプライチェーンのリスクについて、ENISA「サプライチェーン攻撃の脅威状況」を読むでふれたところです。
でもって、サプライチェーンにおけるサイバーリスクが、各企業で、どのように現れてくるのか、というのを考えると、今のところ、ハードウエア、ソフトウエアのそれぞれの場面を考える必要があるということで考えています。
ソフトウエアのサプライチェーンにおけるサイバーリスク対応という観点で考えると、SBOM (Software Bill of Material）あたりで、分析するのが一番、流行りっぽいなあ、ということでちょっと調べました。ちょうど、参考なったのは、「「サイバー・フィジカル・セキュリティ対策フレームワーク」策定後のWG1の進め⽅（案）」という資料です。
サプライチェーンのリスクマネジメントについての関係は、11ページ以降です。
2018年10⽉30⽇、国⼟安全保障省（DHS）は国家保護・プログラム局（NPPD）のサイバーサプライチェーンリスクマネジメント（C-SCRM）プログラムの⼀つとして、 ICT Supply Chain Risk Management Task Force を設置した
となっています。
ICT Supply Chain Risk Management Task Forceのホームページは、こちらです。
サプライチェーンは、最も弱いリンクによってのみ強固になります。外国の敵対者、ハッカー、犯罪者によるサイバー脅威は、政府や産業界に新たな重大なリスクをもたらしています。悪意のある行為者による継続的、標的的、かつ資金的な攻撃は、サプライチェーンのあらゆる階層にある請負業者、下請け業者、サプライヤーを介して、政府や産業界を脅かします。洗練された脅威の担い手は、情報通信技術（ICT）サプライチェーンの奥深くにある脆弱性を利用して、そこを拠点にさらにサプライチェーン上の機密情報や専有情報にアクセスしようとします。
CISAの国家リスク管理センター（NRMC）が主催するICTサプライチェーンリスク管理（SCRM）タスクフォースは、このような現実に対応するために設立された米国屈指の官民サプライチェーンリスク管理パートナーシップであり、ICTサプライチェーンのセキュリティを強化するためのコンセンサス戦略を特定し、開発するという重要な使命を負っています。
このホームページで興味深いのは、「ICT SUPPLY CHAIN RISK MANAGEMENT TOOLKIT」です。
このうち、「有資格入札者および製造者リストによるサプライチェーンリスクの緩和(Mitigating ICT Supply Chain Risks with Qualified Bidder and Manufacturer Lists)」に目を通してみました。
この中で、サプライチェーンは、
サプライチェーンセキュリティ
- 物理的セキュリティ
- サイバーセキュリティ
- 人的セキュリティ（会社のリーダーシップを含む）
– サプライチェーンのインテグリティ
- ハードウェアのインテグリティ(さらに共通の弱点、偽造防止などがある)
- ソフトウェアのインテグリティ(ソフトウエア開発環境、第三者コンポーネント管理、安全な展開(デプロイ)、アップデート)
– サプライチェーンの回復力
– サプライチェーンの品質
- サプライチェーンマネジメントとサプライヤーガバナンス
にわけて論じられています。
そして、ここで、ソフトウエアのインテグリティで、
ソフトウェアのインベントリとソフトウェア部品表（SBOM）の有用性
という記述があります。
複雑な ICT システム全体におけるソフトウェアのサプライチェーンリスクとして、ソフトウエア開発環境、第三者コンポーネント管理、安全な展開(デプロイ)、アップデートの 4 つの要素があることは、上でふれました。そして、それに対応するために、購入者はシステムまたは製品の一部として提供されるソフトウェアコンポーネントを理解することが重要になります。
これらのコンポーネントには、ユーザへの直接的なインタフェースを持つすべてのアプリケーション、アプリケーションが実行されるオペレーティングシステム、システムに含まれる追加のシステム管理ツールやユーティリティ、ミドルウェア、オペレーティングシステムに含まれないモニタ、センサ、アクセサリのデバイスドライバなどのサブシステムコンポーネント、さらにその下のシステムファームウェア、BIOS（Basic Input／Output System）、その他の低レベルコードなどがあります。また、多くのアプリケーションや管理ツールは、機器に常駐しているのではなく、遠隔地のクラウド上で管理されており、ローカル機器に遠隔地からアクセスしたり、ローカル機器からアクセスされたり、ICTシステム内で機器をまたいで動作することもあります（ピアツーピア）。
ソフトウェアの各コンポーネントは潜在的な攻撃ポイントになります。
有資格入札者のリストの 要件には、
- ICT システムに組み込まれたソフトウェア・コンポーネントのインベントリに関す る要件が含まれる場合
- 入札者または製造者によるSBOMの提供を含む場合
もある。
SBOM は、ICT システムのソフトウェア・コンポーネントとそのソースを一覧にしたものである。必要とされる詳細のレベルは、ミッションまたはユースケースによって異なる場合がある。一部のソフトウェア開発者はSBOMを公開し、コンポーネントとサブコンポーネントのリストを顧客に提供し始めているが、SBOMに関するコンセンサス・スタンダードはまだ存在しない。また、複雑なICTシステムのすべてのソフトウェアコンポーネントのすべてのコードラインのソースをリストアップすることは不可能であり、IPや法的な制約のために詳細を入手できない場合もある。この分野は将来性のある分野であり、米国電気通信情報局（NTIA）のマルチステークホルダープロセスでは、その成熟度を高めるためのガイダンスをまとめている。
となり、NTIAのガイダンスをみます。
SBOM (Software Bill of Material）
ソフト部品構成表といえるもの。以下のイメージのように様々なソフトウェア部品の⼀覧とそのライセンス等で構成
とされています。
米国電気通信情報局（NTIA）のソフトウエアのコンポーネントの透明性のページは、こちらです。
ソフトウェア部品表（SBOM）とは、「ソフトウェアを構築するために使用される様々なコンポーネントの詳細とサプライチェーンの関係を含む正式な記録」である。これは、事実上、原材料のリストまたは網状の一覧表のことである(スライド10)。
スライドの11ぺージでは、ひとつのソフトウエアが、いろいろいな部品から成り立っていることを物語っています。
2ページ目は、
商業利用におけるSBOM様式
● SPDX (ソフトウエアパッケージデータ交換仕様)- https://spdx.github.io/spdx-spec/
● SWID(ソフトウエア識別タグ) – ISO/IEC 19770-2:2015
● CycloneDX – https://cyclonedx.org/docs/1.2/
ソフトウエアの識別子等
● Common Package Enumeration (共通パッケージ列挙)- CPE (NISTのセキュリティ・コンテント・オートメーションプロトコルのひとつ)
● Package URLs (パッケージURL)- PURL
● Software ID tags (ソフトウエアIDタグ)- SWID tag(NISTのプロジェクト)
● Software Heritage persistant ID(ソフト・ヘリテージ・一環ID) – SWHID
となっています。
具体的なフィールドとその記載は、こんな感じです。
METIのスライドは、古き良き部品表が載っていますが、現代社会では、上のような交換仕様のもとで判断されていくことになるかと思います。
