米国CISA Secure by Design Pledgeを調達で読む:署名より進捗を見る

米国CISA Secure by Design Pledgeを調達で読む:署名より進捗を見る 海外動向
この記事は約5分で読めます。

このテーマを取り上げる理由

ソフトウェア調達では、認証、ログ、パッチ、脆弱性開示を購入後に個別交渉する場面がまだ残っています。米国CISASecure by Design Pledge1は、この負担を顧客だけに背負わせず、ベンダー側の製品設計へ戻すための自主誓約です。署名企業かどうかだけで評価を終えず、何が標準機能になり、どの進捗が公開されたかを見ると、日本企業の調達判断にも使える材料になります。

海外で何が起きているか

Secure by Design Pledgeは、オンプレミスソフトウェア、クラウドサービス、SaaSを対象とする自主誓約です。物理製品やIoT機器は対象外ですが、希望する企業は進捗を示せます。CISA公式ページは、法的拘束力がないことを明記しています。署名企業は、署名から1年以内に7目標へ向けた誠実な取り組みを進め、測定可能な進捗があれば公開します。

7目標は、顧客が運用で困りやすい論点に寄せられています。

  • MFA: 製品全体で利用を増やし、管理者の登録率やフィッシング耐性のある方式を意識します。
  • デフォルトパスワード: 製品横断で共通する初期パスワードを減らします。
  • 脆弱性クラスの削減: SQLインジェクション、XSS、メモリ安全性の問題などから対象を選び、発生率を下げます。
  • セキュリティパッチ: 顧客が修正を適用しやすい仕組みと、EoL2製品からの移行支援を整えます。
  • VDP3: 善意の調査者が報告できる脆弱性開示ポリシーと窓口を公開します。
  • CVEの透明性: 影響度の高い脆弱性を適時に公表し、CWE4やCPEを含む正確な情報を整えます。
  • 侵入証跡: 認証、構成変更、データアクセスなど、顧客が調査に使えるログを提供します。

このPledgeの上位には、2023年10月に更新された共同ガイド「Shifting the Balance of Cybersecurity Risk」があります。CISANSAFBIに加え、日本のNISCJPCERT/CCを含む国際パートナーが参加しました。

CISAの告知は、顧客のセキュリティ成果に責任を持つこと、透明性と説明責任を受け入れること、経営層が主導することの3原則を示しています。

署名だけで評価しない

調達で使うときの判断軸は、署名の有無ではなく、対象製品、公開進捗、顧客負担の3点です。CISA進捗レポート一覧で、署名企業の公開資料をまとめています。一方で、CISA自身が遵守を強制・検証するものではなく、掲載が製品安全性の保証や政府調達基準への適合を意味しないとも明記しています。

そのため、調達審査では「署名済み」を加点項目にするだけでは足りません。購入予定の製品が対象範囲に入るか、MFAやSSOが追加料金なしで使えるか、監査ログの種類と保持期間は何か、パッチ適用率やEoL移行をどう支援するか、VDPとCVE情報を公開しているかを確認します。進捗資料がない場合は、公開予定日と担当部門を確認すると、単なる宣言との差を見分けやすくなります。

日本企業への含意

このPledgeが日本企業へ直接の法的義務を課すわけではありません。ただし、海外SaaSや業務ソフトウェアを選ぶときの比較軸としては実務的です。特に、MFA、SSO、ログを上位プランだけに載せる構成や、パッチ適用を顧客任せにする運用は、導入後の追加費用と復旧時間を押し上げます。

契約前には、7目標をそのまま質問票へ写すのではなく、自社の重要業務に合わせて優先度を付けます。たとえば、外部公開SaaSならMFAと侵入証跡、オンプレミス製品ならパッチとEoL移行、開発ツールなら脆弱性クラス削減とVDPを先に見ます。要件未充足を許容する場合は、代替策、追加費用、期限、承認者を記録します。

業種別影響

  • 金融: 委託先管理と監査証跡の説明が欠かせません。ログの種類、保持期間、追加費用を契約前に確認すると、インシデント時の調査条件を揃えやすくなります。
  • 製造: 長期利用するオンプレミス製品や設備周辺ソフトウェアでは、パッチ提供期間とEoL移行が判断軸になります。IoT機器自体はPledgeの対象外であるため、対象範囲を分けて確認します。
  • IT・SaaS: 自社が調達者であると同時に提供者にもなります。公開VDP、CVE情報、認証機能、ログ提供を製品ロードマップへ置くと、顧客質問への回答を揃えやすくなります。

一枚要約

  • CISA Secure by Design Pledgeは、顧客側の運用負担をベンダー側の製品設計へ戻す自主誓約です。
  • 署名は製品安全性の保証ではありません。対象製品、公開進捗、顧客負担を確認する必要があります。
  • 調達票では、MFA、SSO、ログ、パッチ、EoL、VDP、CVE情報を自社の重要業務に合わせて優先付けします。

今日着手できる3アクション

  • 利用中の重要SaaSを3製品選び、product, MFA, SSO, audit log, retention, extra cost, VDP, EoL の8列で現状を整理します。
  • CISAの進捗レポート一覧で対象ベンダーの公開資料を探し、製品名、対象範囲、公開日、未対応項目を調達台帳へ追記します。
  • 次回の新規調達レビューに、追加料金なしのMFA・SSO、監査ログの種類と保持期間、パッチ提供期間、VDP公開URLの4項目を入れるよう、情シスと調達部門で担当を決めます。

AI×セキュリティの観点

共同ガイドは、AIソフトウェアやモデルも対象に含めています。AIサービスでは、モデル性能だけでなく、管理者MFA、操作ログ、データアクセス記録、脆弱性窓口、更新責任を調達時に確認します。エージェントが外部ツールへ接続する場合は、権限範囲と停止手順も証跡に残すと、導入後の責任分界を説明しやすくなります。

用語ミニ解説

  1. Secure by Design Pledge: CISAが公開した自主誓約です。エンタープライズソフトウェアのベンダーが、7目標へ向けた進捗を示します。
  2. EoL: End of Lifeの略です。製品のサポート終了時点を指し、更新や移行の計画に影響します。
  3. VDP: Vulnerability Disclosure Policyの略です。外部の調査者が脆弱性を安全に報告するための方針と窓口です。
  4. CWE: ソフトウェアの弱点を種類ごとに整理する共通分類です。脆弱性クラスの削減状況を分析するときに使います。

編集後記

セキュリティ機能が存在するかだけでなく、標準で有効か、追加料金が必要か、調査に使えるログが残るかまで見ると、調達の景色が変わります。宣言を読む作業は、ベンダーを褒めるためではなく、導入後の負担を見積もるためにあります。

参考リンク

コメント

タイトルとURLをコピーしました