新たな政府の指令と絶え間ない脅威.、ソフトウェア保護の緊急性が高まる

バイデン大統領が ”Improving the Nation’s Cybersecurity” に関する大統領令 (EO) 14028 に署名してから 1年以上が経ち、標準やコンプライアンスに対する期待がより明確になりました。

米国国立標準技術研究所 (NIST)、予算管理局 (OMB)、およびその他の米国政府機関は、ソフトウェア・サプライチェーンの可視性とセキュリティを促進する一連のベストプラクティス・ガイダンスと指令をリリースしました。 この基準は連邦政府の省庁や請負業者を対象としていますが、重要インフラ業界にもより広範な影響を与えることが予想されます。

さらに、継続的な脅威の活動やイベントは、ソフトウェア・セキュリティの警戒を喚起する役割を果たします。

• ラテンアメリカを拠点とするハッカーグループである Lapsus$ は、主要なテクノロジベンダーである Samsung と NVIDIA に侵入し、ソースコード、製品の回路図、およびコード署名証明書を公開しました。攻撃者は、この情報を使用して将来の攻撃を計画できます。
• Apache Log4J の脆弱性が広く悪用され、リモートでコードが実行されました。 ソフトウェア ライブラリは、コンシューマおよびエンタープライズ・サービスで広く使用されており、この脆弱性により、適切なソフトウェア・サプライチェーンの可視性がない状態でオープンソース・コードが使用されるリスクが増大しました。
• セキュリティインシデントではありませんが、Peter Zaitko、この Twitter社の内部告発者の証言は、不適切なソフトウェア開発ライフサイクル (SDLC) におけるセキュリティとアクセス許可を取り巻くセキュリティリスクを浮き彫りにしています。訴状には、セキュアコーディング手法の不均一な実装と、Twitter社の運用環境における特権アクセス管理の欠如が詳述されています。

EO 14028：連邦政府の取引事業者やソフトウェア セキュリティ基準を引き上げるだけではない

大統領令は、違反通知、ゼロトラスト、ネットワーク可視性の強化など、さまざまなサイバーセキュリティの課題に対処を求めていますが、ソフトウェアサプライチェーンのセキュリティは圧倒的な優先事項として浮上しています。主な指令には、新しいソフトウェア セキュリティ基準とベスト プラクティスの開発、ソフトウェア部品表（SBOM）の成熟、ソフトウェア コード テストの期待の形式化、Internet of Things（IoT）のサイバーセキュリティ標準の開発が含まれ、いくつかの機関は、EO の期待を満たすためのガイダンスと指令を作成しています。

• NIST の Definition of Critical Software （クリティカルソフトウェアの定義 ）は、クリティカル（重要）と見なされるソフトウェアの基準と属性、および “EO-critical software” の使用に対するセキュリティ対策を確立しています。
• Minimum Standards for Developer Verification of Software（ソフトウェアの開発者検証の最低基準）に関する NISTのガイドラインは、主要なテストと検証手段を確立しています。
• 商務省（実際には下部組織のNTIA）による Minimum Elements for an SBOM

先日、EO の原則の実装に関連して、OMB は NIST の Secure Software Development Framework (SSDF) の採用を促進する 2 つのメモを発行しました。3月になり、OMB は米国政府機関に対し、ソフトウェア製品を提供するすべてのベンダーに NIST SSDF を採用するよう指示し、このフレームワークをベストプラクティスとコンプライアンスの信頼できるリファレンスとして正式なものにしました。9月には、政府機関がセキュアなソフトウェア開発慣行を通じてソフトウェア サプライ チェーンのセキュリティを強化することを求めるメモを公開しました。メモの中で、OMB は、米国政府のベンダーが、セキュアなソフトウェア開発の実践と証明を含む EOのガイドラインを実装するために必要な手順を明確にしています。このメモは、まだ定義されていない標準化された形式を活用した自己認証に傾倒していますが、自己認証が必要な最低限のレベルであることも示しています。ソフトウェアの重要度に基づいて、政府機関は第三者による評価を必要とするリスクベースの決定を下す場合があります。この曖昧さを考えると、米国政府のベンダーは、自己認証と潜在的なサードパーティ サポートの両方の手順を検討する必要があります。

SSDF の 4 つの核となる原則

NIST SSDF (SP 800-218) は、米国政府のソフトウェアセキュリティに対する期待を把握して運用するための中心的な役割を果たします。 2 月には、SP 800-218 が 2020年度の初版から更新され、SSDF を政府の影響力のあるソフトウェアセキュリティの組織化構造として正式なものにしました。このドキュメントは、安全なソフトウェア開発のための一連の基本的なプラクティスについて説明しており、4 つの核となる原則で構成されています。

• Prepare the organization（組織の準備）： セキュアなソフトウェア開発を実行し、維持するために、人、プロセス、テクノロジーを適切に準備する必要があります。
• Protect the software（ソフトウェアの保護）： 組織は、ソフトウェアのすべてのコンポーネントを改竄や不正アクセスから保護する必要があります。
• Produce well-secured software（十分にセキュアなソフトウェアの作成）： 組織は、脆弱性を最小限に抑えた、十分にセキュアなソフトウェアを作成する必要があります。
• Respond to vulnerabilities（脆弱性への対処）： 組織は脆弱性を特定し、適切に対応する必要があります。

各原則には、対応する一連のプラクティス、タスク、および実装例があります。また SSDF は、以前に公開されたベストプラクティス・フレームワーク (BSIMM、OWASP など) に合わせており、この分野ですでに達成されている優れた成果を認めています。

SSDF は、NIST サイバーセキュリティ・フレームワークで採用されているアプローチと同様に、共通言語と一連の高レベルのプラクティスも提供します。しかし、SSDF でのユーザーによるカスタマイズの柔軟性と機会は、解釈の課題と曖昧さにつながる可能性があります。たとえば、SSDF は、定義された各タスクを満たすことができる一連の「概念的な実装例」を示していますが、このリストはすべてを網羅しているわけではなく、自由に解釈できます。組織化の枠組みとしては、柔軟性は歓迎すべきですが、コンプライアンス体制としては、解釈と証明に揺れが発生する可能性があります。

実践者が SSDF への順応を手助けする新しいガイダンス

企業が大統領令に定められた要件を順守できるよう支援するために、Enduring Security Framework (ESF) のソフトウェア・サプライチェーン作業パネル (ESF) は、米国の国家安全保障のセキュリティと安定に対する脅威とリスクに対処する部門横断的なワーキング グループです。システム、 Securing the Software Supply Chainと呼ばれるガイダンスをリリースしました。このガイダンスは、連邦政府向けにソフトウェアを供給、開発、または取得する企業に役立ち、重要なインフラストラクチャのベンダーとバイヤーの新たな要件に対処します。開発者が依存関係を取得し、安全なソフトウェアを統合して構築し、ソフトウェアの整合性を維持および主張しながらソフトウェアを配布するのを支援するアプローチを示しています。

ESF のガイダンスは、より高いレベルの NIST SSDF 原則に直接対応できる実用的な手段を開発者、サプライヤー、および顧客に提供します。次の例は、ガイダンスが SSDF の調整作業を補完し、高まるソフトウェア セキュリティへの期待に対処する方法を示しています。

セキュアなソフトウェアコンポーネントを保守する

バイナリを統合する場合、開発者はバイナリのソフトウェアの構成を解析できるツールを実行し、ソースコードの提供がなくとも脆弱性を見つける必要があります。オープンソース・プロジェクトなど、ソースコードが入手できる場合は、静的解析 (SAST) ツールも活用できます。
SSDF PW.4.1: Acquire well-secured components (e.g., software libraries, modules, middleware, frameworks) from third parties for use by the organization’s software. （組織のソフトウェアで使用するために、十分に保護されたコンポーネント (ソフトウェアライブラリ、モジュール、ミドルウェア、フレームワークなど) をサードパーティから取得する）

ビルド環境をセキュアに

信頼できるコンポーネントをビルド環境に導入する前に、開発者は環境が内部および外部の脅威から保護されていることを確認する必要があります。ESF のガイダンスでは、悪意のある内部関係者の脅威、トレーニングを受けていないエンジニア、不適切なアクセス権、ビルド チェーンの悪用など、さまざまなビルド時の脅威に対処する方法についての情報が提供されます。一般に、企業はビルド環境を外部ネットワークアクティビティから保護し、すべてのアクセスをログに記録し、データ漏洩を監視し、ビルドパイプラインに関連するシークレットを保護するように構成する必要があります。このガイダンスでは、パイプラインのセキュリティに加えて、開発されたソースコードをビルドしてソフトウェアパッケージに統合する際に、ソフトウェアの脆弱性を防止、テスト、軽減、修復するために必要なすべてのアクティビティを実行することにより、ソフトウェアリスクを最小限に抑えることを推奨しています。
SSDF PS.1.1: Store all forms of code—including source code, executable code, and configuration-as-code—based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access.（ソース コード、実行可能コード、コードとしての構成など、すべての形式のコードを最小権限の原則に基づいて保存し、承認された担当者、ツール、サービスなどのみがアクセスできるようにする）

ソフトウェアパッケージへのエクスプロイトの混入を検知・予防する

リスクを最小限に抑える方法でソフトウェアを構築したら、悪意のある改竄を検出または防止する方法で配布する必要があります。これには、侵害されたビルドパイプラインによってソフトウェア パッケージにコンパイルされる可能性のある悪意のあるエクスプロイトを検出して防止することや、侵害されたディストリビューションチャネルがマルウェアやバックドアをソフトウェアに挿入できるようにすることが含まれます。ディストリビューションチャネルを保護する場合、アップロードされるすべてのソフトウェアはバイナリソフトウェアの構成解析 (SCA) を行い、パッケージに脆弱なコンポーネントが含まれていないことを確認する必要があります。バイナリ解析の結果は、開発者が生成した SBOM と比較する必要があり、不一致がある場合は調査する必要があります。
SSDF PW.6.2: Determine which compiler, interpreter, and build tool features should be used and how each should be configured, then implement and use the approved configurations. （どのコンパイラ、インタープリター、およびビルド ツール機能を使用する必要があるか、およびそれぞれをどのように構成する必要があるかを決定し、承認された構成を実装して使用する）

ESF のガイダンスは、企業が提供されたシナリオを SSDF フレームワークを参照し、SSDF コンプライアンスへの準拠を支援できるようにする Appendix（付録）で締めくくられています。