グローバルなソフトウェア サプライ チェーンは常に危険にさらされています。 サイバー犯罪者からの脅威 機密情報や知的財産を盗み、システムの完全性を侵害すると脅迫する者。これらの問題は、営利企業だけでなく、国民に安全かつ確実にサービスを提供する政府の能力にも影響を与える可能性があります。
米国行政管理予算局（OMB）は2022年XNUMX月にこの問題に関するメモを発表し、私たちはそれを取り上げました こちら 詳細に。 2022 年 XNUMX 月に新しいメモが発表されましたが、今回はソフトウェア サプライ チェーンのセキュリティと完全性に焦点を当て、SBOM の重要な役割を強調しました。これは正確な要件のリストを示し、変更を実装するための実際の拘束力のあるタイムラインを初めて共有します。
このメモには、国家のサイバーセキュリティの向上に関する大統領令 (EO) 14028 に関連する XNUMX つの主要なポイントが含まれています。
- EO は、ソフトウェア サプライ チェーンのセキュリティ強化を目的とした実践方法の開発に関するガイダンスを共有するよう国立標準技術研究所 (NIST) に指示します。これを達成するために、NIST は 2 つの文書をリリースしました。Secure Software Development Framework (SSDF)、 SP800-218, ソフトウェア サプライ チェーンのセキュリティ ガイダンス。これらはまとめて NIST ガイダンスと呼ばれ、安全なソフトウェアを作成するための基盤を構成する一連の実践方法の概要を示しています。
- また、EO は管理予算局に対し、各機関が NIST ガイダンスやその他の最新情報に従うよう要求し始めるよう指示しています。
自己証明は必須条件ですが、それだけですべてなのでしょうか？
ソフトウェア制作者は現在、ソフトウェアの使用を開始する前に代理店に自己証明書を与えることが義務付けられています。実際には、自己認証が必要なカテゴリは、新しいソフトウェアの購入、メジャー バージョンのアップグレード、およびソフトウェアの更新の 3 つです。目標は、政府機関を次のような脅威から保護する安全で回復力のあるソフトウェア製品を装備することです。 SolarWinds 経験豊富なため、いくつかの機関が侵害されました。
基本的なことから始めましょう。自己認証とは正確には何ですか?
自己証明書は、ソフトウェア製造者が NIST ガイドラインの慣行に準拠していることを証明する、適合性宣言のように機能する文書です。このアイデアは、代理店がメモの要件に該当するすべてのサードパーティ ソフトウェア製品またはサービスについて自己証明書を取得できるようにすることです。これには、ソフトウェアの更新やメジャー バージョンのアップデートが含まれます。
このメモのもう 1 つの重要な点は、代理店がソフトウェア会社に製品を包括的にするよう奨励することです。これにより、すべての購入代理店に同じ証明書を提供できるようになります。
ソフトウェア会社が自己証明書を公開し、提案書内でその投稿へのリンクを提供しない限り、政府機関は自己証明書を保持することができます。
注: これまでの他のすべてのメモやガイドラインでは、最初は自己証明で十分であると主張されていますが、このメモでは、信頼と透明性が重要な目標として設定されています。サイバーセキュリティや SSDF (一部であっても) だけでなく、特にソフトウェア サプライ チェーンに焦点を当てています。
ソフトウェア会社が標準形式で自己証明書を提供できない場合はどうなりますか?
ソフトウェア製造者は、標準の自己証明フォームで特定されている NIST ガイダンスの 1 つ以上の実践を証明できない場合があります。この場合、ソフトウェアを要求する代理店は企業に次のことを要求します。
- 証明できない慣行を特定する
- それらのリスクを軽減するために使用されているすべての実践を文書化する
- 行動計画とマイルストーン (POA&M) を作成する
当然のことながら、政府機関は、文書が (ベンダーまたは機関自体によって) 公開されないようにする必要があります。
ベンダーがすべての文書を提供し、それが代理店にとって満足のいくものであると仮定します。この場合、後者は、作成者が完全な自己認証を行っていないにもかかわらず、ソフトウェア製品またはサービスを使用する可能性があります。
受け入れられる自己証明書には何を含める必要がありますか?
自己証明書には次の最小要件が含まれている必要があります。
- ソフトウェア会社の名前
- ステートメントが参照するソフトウェア製品の説明 (理想的には、この点は、代理店に提供されるすべての未分類の製品を含む、ソフトウェア会社または製品ライン レベルを説明します)
- ベンダーが安全な開発慣行およびタスクに沿って運営していることを確認する声明 (自己証明書フォームに項目化されている)
このタイプの自己証明書は最低限必要なレベルです。それでも、政府機関が、たとえばソフトウェアの重要性を理由に、ソフトウェアを使用せずにソフトウェアを調達したい場合は、サードパーティの評価 (定義: M-21-30).
それでもこの指令は、政府機関に対し標準の自己証明書フォームを使用するよう奨励している。連邦調達規制（FAR）評議会は、そのような標準的で統一された自己証明フォームの使用に関する規則作成を提案する予定です。
オープンソース ソフトウェアの自己証明書
政府機関がオープンソース ソフトウェア、またはオープンソース コンポーネントを含むソフトウェア製品を取得したいと考えているとします。その場合、認定された FedRAMP 第三者評価機関 (3PAO) が提供する第三者評価、またはその機関自体が承認した評価を利用することができます。
3PAO が NIST ガイダンスをベースラインとして使用している限り、このような評価はベンダーの自己認証の代わりに受け入れられます。
SBOM は業界標準になりつつあります。準備はできていますか?
自己認証は最低限必要なレベルですが、代理店が入手しようとしている製品やサービスが重要であり、標準形式で自己認証を提供できない場合は、自己認証が必要ない場合があります。
重要なのは、このメモが政府機関に対し、安全なソフトウェア開発慣行への適合性を証明するベンダーから成果物を入手するよう奨励していることだ。そのような実践の 1 つとして、SBOM の導入が挙げられます。
SBOM とは何ですか?またどのように機能しますか?
SBOM は、ソフトウェア部品表、つまりソフトウェア製品の開発と提供の一部であるすべてのコンポーネントと依存関係の一覧表を指します。
代理店が要求する場合があります SBOM 政府機関に対するソフトウェアの重要性に応じて、要請要件の一部として。
このメモには、政府機関による SBOM の調達と使用に関する次のガイドラインが含まれています。
- ソフトウェア制作者が SBOM を公開し、それへのリンクを代理店と共有しない限り、代理店は SBOM を保持できます。
- SBOM は、で定義されているデータ形式のいずれかを使用して生成する必要があります。 NTIAレポート 「ソフトウェア部品表 (SBOM) の最小要素」または、 サイバーセキュリティおよびインフラストラクチャセキュリティ機関.
- SBOM を検討する場合、政府機関は、SBOM と他の機関が維持するソフトウェア制作者からのその他の成果物の相互関係を考慮する必要があります。これは、アーティファクトの直接の適用可能性と通貨に基づいています。
- 政府機関は、必要に応じて SBOM 以外の成果物 (たとえば、ソース コードの整合性を検証したり、脆弱性のチェックを実行したりするための自動ツールやプロセスに関連する成果物) を要求する場合があります。
- また、政府機関はソフトウェア会社に対して、 脆弱性開示プログラム.
このメモでは、代理店が買収プロセスのできるだけ早い段階でこれらの要件についてベンダーに通知することも示唆されている。この命令と NIST ガイダンスに準拠するには、政府機関は適切に計画を立て、ソフトウェア評価プロセスにすべての要件を含める必要があります。これはメモで指定されたタイムラインとも一致している必要があることに注意してください (これについては次のセクションで説明します)。
代理店は、提案依頼書 (RFP) またはその他の要請文書で要件を指定する必要があります。ここでの考え方は、代理店がベンダーが実装および使用することを保証することです。 安全なソフトウェア開発実践 ソフトウェア開発ライフサイクル全体を通じて NIST ガイダンスに準拠しています。
SBOM は、特に問題を軽減するために、広く使用されるようになるための業界のベスト プラクティスであることは明らかです。 ソフトウェアサプライチェーンのリスク.
企業が自社のソフトウェア製品に対する信頼を築けるよう、当社は最近、SBOM の生成と組織内および組織間での共有を支援する使いやすいプラットフォームを立ち上げました。 試してみる SBOM の生成、管理、共有がいかに簡単であるかを無料で確認できます。
これはもはや単なる推奨ではありません。今では従う義務のあるタイムラインが存在します
政府機関は、次のスケジュールに沿ってメモの要件に従う必要があります。
- 機関は持っています 90日 「重要なソフトウェア」の個別のインベントリを含む、すべてのサードパーティ ソフトウェアのインベントリを作成します。
- 中で 120日、「この覚書の関連要件をベンダーに伝達し、ソフトウェアプロバイダーによって公的に投稿されていない証明書レターが単一の中央機関システムに収集されることを保証するための一貫したプロセス」を作成する必要があります。
- 彼らも持ってる 270日 「重要なソフトウェア」に関して公に投稿されていない証明書を収集する。 1 年以内に、代理店はすべてのサードパーティ ソフトウェアに関するレターを収集する必要があります。
- 最後に、 180日 メモの日付 (14 年 2022 月 XNUMX 日) 以降、政府機関の CIO はトレーニングのニーズを評価し、証明書文書と成果物をレビューおよび検証するためのトレーニング計画を作成する必要があります。
政府機関は、未解決の要件を満たすための計画とともに、メモに記載されている関連期限の少なくとも 30 日前までに延長を要請することができます。免除をリクエストすることも可能ですが、例外的な状況および限られた期間に限ります。
まとめ
OMBは、メモの日付から90日以内（2022年XNUMX月中旬まで）に免除または延長のリクエストを提出するための具体的な手順を共有します。さらに、CISA および一般調達局と協議して、政府機関間での保護と共有のための適切なメカニズムを備えた「ソフトウェア証明書およびアーティファクトの集中リポジトリ」の要件を決定します。
このような中心的な場所は、いつか自己証明書フォームや SBOM を超えたさまざまなセキュリティ証拠や証明書の中心となる場所になる可能性があります。すべての証拠を単一の共有可能な場所に配置すると、組織は新たなエクスプロイトや CVE などの共有の問題に対処できます。
これはまさに Scribe のすべてです。を見てみましょう このページ 組織内および組織間で SBOM を生成、管理、共有するための包括的なプラットフォームについて詳しく学びます。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
