2022 年 XNUMX 月、米国管理予算局 (OMB) は、 ランドマークメモ ソフトウェア サプライ チェーンを米国連邦政府が許容できる程度に保護するために必要な手順について説明します。ソフトウェアを製造する政府および連邦政府機関と取引を希望する企業は、法令に規定されている要件とスケジュールに従う必要があります。 M-22-18メモ.
M-22-18 は、ソフトウェア サプライ チェーンのセキュリティと完全性に焦点を当て、特にソフトウェア サプライ チェーンの役割に注意を払いました。 SBOM。これには、要件のリストと、コンプライアンスに必要な手順を実装するためのスケジュールが含まれていました。
このメモでは、NIST が作成した 2 つの主要文書が確立されました。 セキュア ソフトウェア開発フレームワーク (SSDF)、 SP800-218, ソフトウェア サプライ チェーンのセキュリティ ガイダンス 安全なソフトウェア開発に関する NIST のガイダンスとして。このメモでは、連邦政府機関が製品を自由に使用できるようになる前に、ソフトウェア製造者が NIST のガイダンスに準拠していることを自己証明する責任についても概説されている。この自己証明書は、署名入り自己証明書「共通形式」の形式となります。新しいソフトウェアの購入、メジャー バージョンのアップグレード、およびソフトウェアの更新の 3 つのソフトウェア カテゴリでは、この自己証明書フォームが必要です。
M-22-18 は、CISA に対し、覚書の日付 (120 年 14 月 2022 日) から 120 日以内にこの標準的な自己証明書の「共通形式」を確立することを要求しました。 2023 年 XNUMX 月に XNUMX 日が経過しましたが、フォームはまだ残っています ドラフトフォーム たとえそれに対するコメント期間が26年2023月XNUMX日に終了したとしても。OMBメモが最初に政府機関に重要なソフトウェアの証明書の収集を開始するよう指示したのはほぼその頃だ。
この共通認証フォームに対して受け取ったコメントの一部に基づいて、OMB は 22 年 18 月 9 日に M-2023-XNUMX の修正版をリリースすることが適切であると判断しました。この修正版のタイトルは次のとおりです。 M-23-16. 新しい覚書は、政府機関がソフトウェア制作者から証明書を収集するために、M-22-18 に公開されたスケジュールを延長します。政府機関は現在、 自己証明書「共通形式」 CISA 共通自己証明書フォームが OMB によって承認されてから 3 か月以内に、「重要な」ソフトウェアについてはソフトウェア メーカーからの提出を求められます。他のすべてのソフトウェア製作者は、自己証明書フォームが OMB によって承認されてから 6 か月の猶予が与えられます。
これから 標準的な自己証明書フォームが注目を集めているようですが、その内容をもう少し詳しく見てみましょう。また、署名するのは誰なのか、その署名は何を意味するのかについても見ていきます。
安全なソフトウェア自己証明書の共通フォーム
EO 14028 から NIST のガイダンス文書、OMB メモに至る一連の規制をたどると、政府が連邦機関と民間企業の両方をすべての人を危険から守ることを目指していることは明らかです。 ソフトウェアサプライチェーンの脆弱性 そして侵入。 （政府の見解では）民間部門がこの問題について十分に取り組んでいないため、政府は（連邦政府に販売する）すべての人が従わなければならない新しい規制の創設に着手しました。
もちろん、連邦政府に（まだ）販売していないとしても、そのような企業はより魅力的なビジネスパートナーになるため、これらの規則に従い、自分が「安全」であると自己証明することが最大の利益になります。製品とユーザーを保護するために全力を尽くしていることを確認できない会社と誰が取引したいと思うでしょうか?
NIST ガイダンスが新しい規制とベスト プラクティスの基礎であることはすでに確立されているため、たとえば、 SSDF 自己証明書にも記載されます。
以下は草案文書の短い例です。
セキュア ソフトウェア自己証明書共通フォームのドラフトから抜粋
左側に要件があり、その後に関連する EO セクションがあり、次に SSDF のプラクティスとタスクが続きます。これは、要件のかなり包括的なリスト (1 ページ半) ですが、読者がサイバーセキュリティや DevOps、DevSecOps のビジネスに携わっていない場合、必ずしも完全に明確になるとは限りません。
この文書では、企業の署名者が、フォームに記載されているすべての要件が一貫して維持されていること、およびリスト上の要素が有効でなくなった場合には影響を受ける政府機関に企業が通知することを個人的に証明することが求められています。
この文書には、社内の誰が文書に署名するのかは明記されていないが、このフォームは企業が連邦政府およびその機関と取引するための要件であるため、CEOが責任を負うべき人物であると考えるのは当然である。ここ。おそらく CEO は、やみくもに署名することはなく、CTO と CISO に、会社がこれらのガイドラインと要件をすべて遵守していることを (おそらく書面で) 確認するよう依頼するでしょう。
これらすべての要件を収集して証明するための確立された製品や運用方法がないため、ある意味、署名する各企業は自ら「車輪の再発明」を行い、何も悪いことが起こらないことを祈る必要があります。
何か悪いことが起こった場合、連邦政府は署名者を追跡して、署名者がすべてのフォームの要件を裏付けることができることを証明するでしょう。
署名しないとどうなりますか?
まず、この証明書全体が現時点で関係があるのは、ソフトウェアが連邦政府機関によって使用されている場合、ソフトウェアを連邦政府に販売する予定の場合、またはソフトウェアが使用中のベンダーによって使用されている場合のみです。または連邦政府に販売することを目的としています。
「現在」と述べたことに注意してください。SSDF への準拠が、自己証明またはその他の検証可能な形式で、ソフトウェア制作の分野における新しい「ベスト プラクティス」になる可能性を示すあらゆる兆候があるためです。
したがって、あなたの会社が上記のグループに属し、明確な良心をもってこの文書に署名する方法が見つからないと仮定しても、まだすべてが失われたわけではありません。認証の欠陥がどこにあるのかを説明し、満足のいく内容を提供できる限り、 行動計画とマイルストーン (POA&M) 問題の連邦政府機関は引き続きお客様の製品を購入/使用し、お客様に代わって OMB からソフトウェアの拡張を求めることができます。
悪いニュースは、POA&M 計画の有無にかかわらず、最終的には完全な証明書フォームを提出する必要があることです。これは、フォームで要求されているすべての手順が会社によって実行されたこと、およびあなたの会社がソフトウェア開発プロセスは、少なくともフォームの要件と同じくらい安全です。
現在、この形式の認証が免除されている唯一のソフトウェアは、連邦政府機関が開発したソフトウェアと、自由に利用できるソフトウェア、別名オープンソース ソフトウェアです。もちろん、ほとんどの ソフトウェアサプライチェーンのセキュリティ 何らかの方法でコード内のオープンソース パッケージに穴があることを追跡することはできますが、無料で作業するオープンソースの開発者やメンテナに、ソフトウェアに法的拘束力のある保証を提供することを強制しようとすることには、大きな問題があります。オープンソース ソフトウェアを使用する人は、その一般的な安全性と、特にそのソフトウェアが組み込まれているソフトウェアの安全性を検証する必要があります。
最悪のシナリオ
このソフトウェア サプライ チェーン全体のセキュリティへの配慮は、有名な SolarWinds ハック。詳細にはあまり立ち入らないが、ハッキング当時、18,000つの連邦政府機関を含む同社の顧客9万XNUMX社以上が影響を受けた。
この事件からの法的結果の一部が見え始めたのは、数年後の今になってからだ。 SEC、 米国証券取引委員会、 会社を追っている 全体として、および数名の経営幹部の後で。これは、安全な開発を行っていることを証明しながらもハッキングの被害に遭ったソフトウェア制作者にこのような事件または同様の事件が発生した場合の政府の意図の一例と見ることができます。
ソーラーウィンズの場合、同社はそのような法的措置の対象となった従業員を全面的にバックアップしている。米国の法制度を知ると、このような訴訟には何年もかかり、多額の費用がかかる可能性が高い。罰金は問題外ではなく、推定額に基づくと数百万ドルに達する可能性があります。 被った損害.
すべての企業、特に中小企業が SolarWinds ほど従業員を厳格に保護しているわけではないことは想像できるでしょう。問題は、告発された当事者が会社の CEO である場合、会社とその製品に対する市場の信頼が大きく損なわれる可能性が実際にあることです。潤沢な資金を持つ大企業の支援なしにSECに立ち向かうことは、疑いを持たないCEOとその会社を破滅させる可能性がある。もちろん、その目的は人々に開発を確保する責任を真剣に受け止めてもらうことですが、その恐れが人々を自己保存の側に誤らせるかもしれません。つまり、人々は、潜在的な SEC 訴訟で勝てないと考える場合、またはそのような訴訟の費用と悪評が非常に深刻であるため、裁判の結果に関係なく、サイバーセキュリティインシデントを隠したほうが良いと考える場合、むしろサイバーセキュリティインシデントを隠すことを好むことになります。
どうすれば署名できますか?
NIST SSDF ガイダンスは提案とベスト プラクティスに満ちていますが、実用性については軽視されています。企業にはそれぞれ個性があるため、すべての人に適した製品やシステムを生み出すのは非常に困難です。この場合、民間部門が空白を埋めるために介入し、要件を満たすのに役立つエコシステムを構築します。
たとえば、 Scribe がプラットフォームを構築 証明書の作成、署名、検証機能の提供という概念に基づいています。に合わせて作成されたドキュメントをまもなくリリースします。 CISA 自己証明書フォームでは、Scribe ソリューションが要件の各セクションでどのように役立つかを示します。乞うご期待。
試してみます Scribe のプラットフォームは無料です。ぜひ試してみて、プラットフォームを要件に適合させ、同時に明確な良心をもって CISA の自己証明書フォームに署名する方法を確認することをお勧めします。
このコンテンツは、エンドツーエンドのソフトウェア サプライ チェーン セキュリティ ソリューションの大手プロバイダーである Scribe Security によって提供されており、ソフトウェア サプライ チェーン全体のコード成果物とコード開発および配信プロセスに最先端のセキュリティを提供しています。 詳しくはこちら。
関連記事
