そのソフトウェア、購入して大丈夫？ 企業が調達するにあたり製造業者に質問すべきこと・考慮すべきこととは？

　企業や組織が使用する製品のサプライチェーンセキュリティが注目を集める中、米サイバーセキュリティ・インフラセキュリティ庁（Cybersecurity & Infrastructure Security Agency、以降CISA）は「Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem（セキュアバイデマンド・ガイド：ソフトウェアの顧客によるセキュアな技術エコシステムの推進を可能にする方法）」を公開しました。

米CISAが公開した「Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem」冒頭の概要部分

　このガイドは、ソフトウェアを購入する際に尋ねるべき質問や、製品セキュリティを調達ライフサイクルの各段階に統合するための考慮事項、セキュリティバイデザインの原則に沿って製品セキュリティの成熟度を評価するためのリソースを提供するものです。なお、以前公開された別のガイド「Software Acquisition Guide for Government Enterprise Consumers: Software Assurance in the Cyber-Supply Chain Risk Management (C-SCRM) Lifecycle（政府企業消費者向けソフトウェア調達ガイド：サイバー・サプライチェーン・リスクマネジメント（C-SCRM）ライフサイクルにおけるソフトウェア保証）」を補完するものとされていますが、今回公開されたガイドは政府企業（government enterprise）向けに特化したものではなく、一般的な企業や組織にも適用できる内容となっています。

　ガイドの内容はPDFでも3ページ強とコンパクトにまとまっており、以下のような構成となっています。

• 概要（Overview）
• ソフトウェア製造業者についての質問（Software Manufacturer Questions）
  
  • 一般的な質問（General Questions）
  • 認証（Authentication）
  • 脆弱性クラスの排除（Eliminating Classes of Vulnerability）
  • 侵入の証拠（Evidence of Intrusions）
  • ソフトウェアサプライチェーンセキュリティ（Software Supply Chain Security）
  • 脆弱性の開示と報告（Vulnerability Disclosure and Reporting）
• さらなる情報の入手先（Where to go for Further Information）

　今回はこの中から「ソフトウェア製造業者についての質問」を紹介します。

一般的な質問

• その製造業者はCISAの「セキュアバイデザイン誓約書」に署名しているか？　誓約に対するコミットメントに沿って、その製造業者はどのような進捗報告書を公表しているか？
• その製造業者は顧客がセキュリティパッチをインストールしやすくするためにどのようなことをしているか？　広範囲にわたってセキュリティパッチのサポートを提供し、自動更新機能を有効にしているか？

これが重要な理由： 誓約を行なった企業は、セキュアバイデザインのソフトウェアを製造するための手順を講じ、それを実証することを公に約束している。この約束は、あなたが使用する製品をセキュアにするのに役立つだけでなく、我々の重要インフラが依存する技術をセキュアにすることによって、全てのアメリカ人を保護するのに役立つだろう。

認証

その製品はセキュアな認証をサポートすべきである。

• その製造業者は、追加コストなしで顧客に標準ベースのシングルサインオン（SSO）の統合をサポートしているか？
• そのソフトウェア製造業者が認証を管理する場合、デフォルト、かつ無料で多要素認証（MFA）やパスキーのようなフィッシング耐性のある他の認証形式を有効にしているか？
• そのソフトウェア製造業者は製品からデフォルトパスワードを排除しているか？　そうでない場合、製品ライン全体でデフォルトパスワードの使用を減らすよう取り組んでいるか？

これが重要な理由： CISAが定義するデフォルトパスワード、つまり製品全体でデフォルトで存在する普遍的に共有されたパスワードは、悪意のあるサイバー活動を可能にし続けている。デフォルトパスワードは、ランダムで、インスタンス固有のパスワードなど、よりセキュアな認証メカニズムに置き換えるべきである。さらに、MFAはパスワードベースの攻撃、例えばクレデンシャルスタッフィングやパスワード盗難に対する最大の防御である。どのような形式のMFAでも、そのような活動の成功を大幅に減らすことが示されており、フィッシング耐性のあるMFAのような、よりセキュアな形式のMFAは、標的型の活動に対してさらなる保護を提供する。

脆弱性クラスの排除

そのソフトウェア製造業者は、製品全体にわたってソフトウェア欠陥の全クラスに体系的に対処すべきである。

• そのソフトウェア製造業者は製品においてどのような脆弱性クラスに体系的に対処しているか？
• まだ対処していないものについて、それらの脆弱性クラスを排除する計画をどのように立てているかを示すロードマップはあるか？　以下の戦略は健全でセキュアな開発プロセスに沿ったものである。
  
  • SQLインジェクション攻撃を防ぐためのパラメータ化されたクエリの使用を一貫して強制する。
  • クロスサイトスクリプティング脆弱性に対する組み込み保護機能を持つWebテンプレートフレームワークを採用する。
  • 優先順位を付けてコードをメモリセーフなプログラミング言語に移行し、新製品をメモリセーフなプログラミング言語で書く。
  • 開発者にセキュアなデフォルトを提供する。例えば、特定の脆弱性クラスの導入を不可能（または著しく困難）にするセキュアな関数やライブラリの「ビルディングブロック」を提供する。

これが重要な理由： 今日悪用されている脆弱性の大部分は、大規模に防ぐことができる脆弱性クラス（または製品の欠陥）によるものである。ソフトウェア製造業者は、製品全体で脆弱性のクラスを防止・排除するよう取り組むことで、顧客のリスクを低減できる。

侵入の証拠

ソフトウェア製造業者は、製品のベースラインバージョンでも顧客がセキュリティログを利用できるようにすべきである。クラウドサービスプロバイダやSaaSプロバイダーの場合、そのソフトウェア製造業者は追加料金なしで少なくとも6カ月間セキュリティログを保持し、顧客が利用できるようにすべきである。ログは以下のような領域をカバーすべきである。

• 構成変更または構成設定の読み取り
• 該当する場合、ID（例えば、サインインとトークン作成）とネットワークフロー
• ビジネス関連データへのアクセスまたは作成

これが重要な理由： 発生したサイバーセキュリティインシデントを組織が検出し、何が起こったかを理解する能力を持つことは不可欠である。ソフトウェア製造業者は、顧客の監査ログなど、侵入の証拠を収集するためのアーティファクトと機能を提供することで、顧客がそれを行なえるようにすることができる。そうすることで、ソフトウェア製造業者は顧客のセキュリティ成果に対する責任を持つというセキュアバイデザインの原則を体現できる。

ソフトウェアサプライチェーンセキュリティ

そのソフトウェア製造者は、サードパーティの依存関係の出所データを維持・共有し、オープンソースソフトウェアコンポーネントの使用とそれへの貢献を管理するプロセスを持つべきである。

• その製造業者は標準的な機械可読形式でソフトウェア部品表（SBOM）を生成し、これを顧客が利用できるようにしているか？　SBOMはオープンソースソフトウェアコンポーネントを含むすべてのサードパーティの依存関係を列挙しているか？
• そのソフトウェア製造業者は、組み込んでいるオープンソースソフトウェアコンポーネントのセキュリティの検証、およびそれらのオープンソースプロジェクトの持続支援への貢献の促進を、どのように行なっているか？　そのソフトウェア製造業者は、オープンソースプログラムオフィス（open source program office: OSPO）などを通じて、そのための確立されたプロセスを持っているか？

これが重要な理由： ソフトウェア製造業者は、サードパーティの依存関係のセキュリティを自社のセキュリティの延長として扱うべきである。そのために、ソフトウェア製造業者は継続的に依存関係の出所データを維持し、これを顧客と共有し、オープンソースソフトウェアコンポーネントの使用とそれへの貢献を（OSPOなどを通じて）管理するプロセスを確立すべきである。

脆弱性の開示と報告

そのソフトウェア製造業者は、オンプレミス製品とクラウド製品の両方について、脆弱性報告の透明性と適時性を示すべきである。

• そのソフトウェア製造業者は、自社製品の全てのCVEレコードに正確な共通脆弱性タイプ一覧（CWE）と共通プラットフォーム一覧（CPE）のフィールドを含めているか？
• そのソフトウェア製造業者は、自らが提供する製品に対して、一般市民によるテストを許可する脆弱性開示ポリシーを公表しているか？

これが重要な理由： 顧客が脆弱性から保護するために取るべき行動を標準化された方法で伝えることに加えて、適時で正確かつ完全なCVEレコードによって、長期にわたって脆弱性の傾向を公開するという透明性を確保できる。これは個々の企業とその顧客、そしてソフトウェア業界全体にとって有益であり、ソフトウェア開発者は最も差し迫った脆弱性クラスをより良く理解できるようになる。CVEの発行はSaaS製品にとっても価値があることが指摘されているが、これが標準的な慣行になり始めたのはごく最近のことであるのは確かである。協調的な脆弱性開示は、セキュリティ研究者との関わりにおいて相互に有益な規範として浮上してきている。脆弱性開示ポリシーを確立しているソフトウェア製造業者は、セキュリティ研究コミュニティからの支援を受けることで自社製品のセキュリティをより強化できるというメリットがある。一方、セキュリティ研究者は、脆弱性を報告するための明確なチャネルに加え、このポリシーの下でテストを行なう許可を得られる。

　今回紹介した「ソフトウェア製造業者についての質問」は、CISAの「セキュアバイデザイン誓約書」への署名といった米国ならではの項目もありますが、基本的にはどの国のどのような組織にとっても（その質問を相手に対して実際にできるかどうは別として）十分に参考になる内容となっています。厳し目の内容ですが、うまく活用してください。