📘

Secure by Design 原則 日本語訳 - セキュア・バイ・デザインなソフトウェアのための原則とアプローチ

に公開
1件
デザイン
Security
translation
vulnerability
idea

本記事は、米国CISA（Cybersecurity and Infrastructure Security Agency）が2023年に公開した「Secure By Design - Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software」version 1025 508c」を個人が翻訳したものです。
原文: https://www.cisa.gov/resources-tools/resources/secure-by-design
ライセンス: パブリックドメイン
免責事項: この翻訳は非公式なものであり、CISAが内容を保証するものではありません。正確な情報については原文を参照してください。

概要：脆弱なデザイン (VULNERABLE BY DESIGN)

テクノロジーは日常生活のほぼすべての側面に統合されており、インターネットに接続されたシステムは、個人のID管理から医療に至るまで、私たちの経済的繁栄、生活、さらには健康に直接影響を与える重要なシステムに私たちを結びつけています。このような利便性の裏にある欠点の一例として、世界的なサイバー侵害により病院が手術をキャンセルし、患者のケアを他に回さざるを得なくなった事例があります。安全でないテクノロジーや重要システムの脆弱性は、悪意あるサイバー侵入を招き、潜在的な安全（セーフティ）リスクにつながる可能性があります。

その結果、ソフトウェア製造者（ベンダー）にとって、「セキュア・バイ・デザイン（設計から安全に）」と「セキュア・バイ・デフォルト（初期状態で安全に）」を製品の設計および開発プロセスの焦点にすることが極めて重要になっています。一部のベンダーはソフトウェア保証において業界を前進させる大きな進歩を遂げていますが、遅れをとっているベンダーも存在します。

本ガイドの執筆組織は、すべてのテクノロジー製造者に対し、顧客のサイバーセキュリティの負担を軽減することに基づき製品を構築することを強く推奨します。これには、サイバー侵入を緩和するために顧客が常に監視、定期的な更新、およびシステム上のダメージコントロールを行う必要がないようにすることも含まれます。また、構成、監視、および定期的な更新の自動化を促進する方法で製品を構築することも強く求めます。製造者は、顧客のセキュリティ成果（Security Outcomes）を向上させることに責任を持つことが推奨されます。

歴史的に、ソフトウェア製造者は、製品の導入後に発見された脆弱性の修正に依存しており、顧客に自費でパッチを適用することを求めてきました。「セキュア・バイ・デザイン」の実践を取り入れることによってのみ、修正プログラムを作成し適用し続けるという悪循環を断ち切ることができます。
注：「セキュア・バイ・デザイン」という用語は、文脈により「セキュア・バイ・デザイン」と「セキュア・バイ・デフォルト」の両方を包含します。

この高い水準のソフトウェアセキュリティを達成するために、執筆組織は製造者に対し、機能や市場投入のスピードよりも、製品セキュリティの統合を重要な前提条件として優先することを推奨します。時間の経過とともに、エンジニアリングチームは、セキュリティが真に設計に組み込まれ（designed-in）、維持にかかる労力が少なくなるような、新しい定常状態のリズムを確立できるようになるでしょう。

この視点を反映し、欧州連合（EU）は「サイバーレジリエンス法（Cyber Resilience Act）」において製品セキュリティの重要性を強化しており、製造者が脆弱な製品を市場に投入するのを防ぐために、製品のライフサイクル全体を通じてセキュリティを実装すべきであることを強調しています。

執筆組織は、「安全（Safety）」という用語が文脈によって複数の意味を持つことを認識しています。本ガイドの目的において、「安全」とは、悪意あるサイバー活動から顧客を保護するためにテクノロジーのセキュリティ基準を引き上げることを指します。

ビジョン

テクノロジーと関連製品が顧客にとってより安全な未来を創造するために、執筆組織は製造者に対し、設計および開発プログラムを刷新し、「セキュア・バイ・デザイン」および「セキュア・バイ・デフォルト」な製品のみを出荷することを許可するよう強く求めます。

  • セキュア・バイ・デザインな製品 は、開発のかなり前の段階から、顧客のセキュリティを単なる技術的機能ではなく、ビジネスの中核的な目標として概念化されています。開発が始まる前にその目標からスタートします。既存の製品も、複数回のイテレーション（反復）を経てセキュア・バイ・デザインな状態へと進化させることができます。
  • セキュア・バイ・デフォルトな製品 とは、追加の設定変更をほとんど、あるいは全く必要とせず「箱から出してすぐに（out of the box）」安全に使用でき、追加費用なしでセキュリティ機能を利用できる製品のことです。

これら2つの哲学を合わせることで、セキュリティ維持の負担の多くを製造者に移し、設定ミスや顧客によるパッチ適用の遅れ、その他多くの一般的な問題に起因するセキュリティインシデントの被害に顧客が遭う可能性を減らします。

米国サイバーセキュリティ・社会基盤安全保障庁（CISA）、国家安全保障局（NSA）、連邦捜査局（FBI）、および以下の国際パートナーは、ソフトウェア製造者が製品のセキュリティを確保するためのロードマップとして、本ガイドの推奨事項を提供します。

  • オーストラリア・サイバーセキュリティ・センター (ACSC)
  • カナダ・サイバーセキュリティ・センター (CCCS)
  • 英国・国家サイバーセキュリティ・センター (NCSC-UK)
  • ドイツ・連邦情報セキュリティ局 (BSI)
  • オランダ・国家サイバーセキュリティ・センター (NCSC-NL)
  • ノルウェー・国家サイバーセキュリティ・センター (NCSC-NO)
  • ニュージーランド・コンピュータ緊急対応チーム (CERT NZ) および ニュージーランド・国家サイバーセキュリティ・センター (NCSC-NZ)
  • 韓国インターネット振興院 (KISA)
  • イスラエル国家サイバー局 (INCD)
  • 日本・内閣サイバーセキュリティセンター (NISC) および JPCERTコーディネーションセンター (JPCERT/CC)
  • OAS/CICTE 南北アメリカ政府CSIRTネットワーク (CSIRT Americas)
  • シンガポール・サイバーセキュリティ庁 (CSA)
  • チェコ共和国・国家サイバー情報セキュリティ庁 (NÚKIB)

執筆組織は、多くの民間セクターのパートナーがセキュア・バイ・デザインおよびセキュア・バイ・デフォルトの推進に貢献していることを認識しています。この成果物は、テクノロジーが設計およびデフォルトで安全かつ強靭である未来を実現するために必要な主要な優先事項、投資、決定についての国際的な対話を前進させることを意図しています。

新着情報 (WHAT'S NEW)

本レポートの初版は、ソフトウェア業界内で大きな議論を呼びました。組織や個人が侵害されたという日々のニュースは、ソフトウェア製品における慢性的かつ体系的な問題にどう対処するかについての対話がさらに必要であることを浮き彫りにしています。

2023年4月のリリース後、執筆組織（以下「私たち」）は、数百の個人、企業、業界団体から思慮深いフィードバックを受け取りました。フィードバックで最も多かった要望は、ソフトウェア製造者とその顧客の両方に適用される3つの原則について、より詳細な情報を提供してほしいというものでした。

本書では、元のレポートを拡張し、製造者と顧客の規模、顧客の成熟度、原則の適用範囲などの他のテーマにも触れています。ソフトウェアはあらゆる場所に存在し、単一のレポートでソフトウェアシステムの全範囲、製品開発、顧客による展開と保守、他システムとの統合を適切にカバーすることはできません。以下のガイダンスが特定の環境に明確に当てはまらない場合、本書で説明されている実践がどのように特定のセキュリティ改善につながったかについて、コミュニティからの意見を期待しています。

本レポートは、人工知能（AI）ソフトウェアシステムおよびモデルの製造者にも適用されます。これらは従来のソフトウェアとは異なる場合がありますが、基本的なセキュリティ対策は依然としてAIシステムやモデルにも適用されます。一部のセキュア・バイ・デザインの実践は、AI固有の考慮事項を考慮して修正が必要になる場合がありますが、3つの包括的なセキュア・バイ・デザイン原則はすべてのAIシステムに適用されます。

私たちは、ソフトウェア開発ライフサイクル（SDLC）をこれらのセキュア・バイ・デザイン原則に沿うように変革することは簡単なタスクではなく、時間がかかる可能性があることを認識しています。さらに、小規模なソフトウェア製造者は、これらの提案の多くを実装するのに苦労するかもしれません。私たちは、ソフトウェア業界が製品をより安全にするツールや手順を広く利用できるようにする必要があると考えています。より多くの人々や組織がソフトウェアセキュリティの改善に注目するにつれて、すべての顧客の利益のために、大規模および小規模のソフトウェア製造者間のギャップを埋めるイノベーションの余地があると信じています。

このセキュア・バイ・デザインレポートの更新版は、私たちの技術エコシステムを支える多くの相互接続されたステークホルダーコミュニティとのパートナーシップを構築するという私たちのコミットメントの一部です。これは、そのエコシステムの多くの部分からのフィードバックの結果であり、私たちは引き続き様々な視点に耳を傾け、学び続けます。多くの課題が待ち受けていますが、セキュア・バイ・デザインの哲学をすでに採用し、しばしば成功を収めている人々や組織について知るにつれ、私たちは非常に楽観的です。

本書の使い方

私たちは、ソフトウェア製造者が本書の原則を遵守することを強く求めます。ソフトウェア製造者は、以下にリストされているステップに沿って、実施したアクションを公に文書化することで、そのコミットメントを示すことができます。

私たちは、ソフトウェア製造者がこれらの原則の精神を満たす戦術を見つけ、懐疑的な既存および潜在的な顧客に対しても、セキュア・バイ・デザインの哲学を体現していることを納得させるような成果物を作成することを推奨します。

ソフトウェア製造者が取るべきアクションに加えて、顧客も本書を活用できます。ソフトウェアを購入する企業は、本書に記載されている原則の遵守例からインスピレーションを得て、ベンダーに厳しい質問を投げかけるべきです。そうすることで、顧客は市場をよりセキュア・バイ・デザインな製品へとシフトさせる手助けができます。顧客がベンダーに尋ねることができる質問の例は、CISAの「K-12 Technology Acquisitions（K-12向け技術調達ガイダンス）」に記載されています。

私たちは、エンタープライズ顧客に対し、調達プロセス、ベンダーのデューデリジェンス評価、エンタープライズリスクの受容決定、およびベンダーを評価する際のその他のステップに、これらの実践を組み込むことを推奨します。

また、顧客はベンダーに対し、各ベンダーが実施しているセキュア・バイ・デザインのアクションを公に文書化するよう強く求めるべきです。これらが集まることで、セキュリティに対する強力な需要シグナルが生まれ、ソフトウェア製造者がより高いセキュリティに向けて一歩を踏み出すことを奨励し、可能にします。言い換えれば、ソフトウェア製造者内に「セキュア・バイ・デザイン」の哲学を浸透させようとするのと同様に、顧客と共に「セキュア・バイ・デマンド（需要によるセキュリティ）」の文化を創造する必要があります。

セキュア・バイ・デザイン (Secure by Design)

「セキュア・バイ・デザイン」とは、テクノロジー製品が、悪意あるサイバー攻撃者がデバイス、データ、接続されたインフラストラクチャへのアクセスを成功させることに対して合理的に保護されるように構築されていることを意味します。ソフトウェア製造者は、リスク評価を実施して重要システムに対する一般的なサイバー脅威を特定し、列挙した上で、進化するサイバー脅威の状況を考慮した保護策を製品の設計図（ブループリント）に含めるべきです。

安全な情報技術（IT）開発の実践と、「多層防御（defense-in-depth）」として知られる多層的な防御も、悪意ある攻撃者がシステムを侵害したり、機密データへの不正アクセスを取得したりするのを防ぐために推奨されます。執筆組織はさらに、製造者が製品開発段階で「調整された脅威モデル（tailored threat model）」を使用し、システムに対するすべての潜在的な脅威に対処し、各システムの展開プロセスを考慮することを推奨します。

執筆組織は、製造者が製品とプラットフォームに対して包括的なセキュリティアプローチをとることを強く求めます。セキュア・バイ・デザインな開発には、製品設計および開発プロセスの各層において、ソフトウェア製造者が専用のリソースを戦略的に投資する必要があり、これは後から「付け足す（bolt on）」ことはできません。セキュリティを単なる技術的機能ではなくビジネスの優先事項とするためには、製造者のトップビジネス幹部による強力なリーダーシップが必要です。ビジネスリーダーと技術チームの間のこの協力関係は、設計と開発の予備段階から、顧客による展開と保守に至るまで及びます。

製造者は、顧客には「見えない」投資（例えば、広範な脆弱性を排除するプログラミング言語への移行など）を含め、困難なトレードオフや投資を行うことが推奨されます。見栄えは良いが攻撃対象領域（アタックサーフェス）を拡大してしまう製品機能よりも、顧客を保護する機能、メカニズム、ツールの実装を優先すべきです。

悪意あるサイバー攻撃者が技術的な脆弱性を悪用する持続的な脅威を終わらせる単一の解決策はなく、「セキュア・バイ・デザイン」な製品であっても脆弱性は引き続き発生します。しかし、大多数の脆弱性は、比較的少数の根本原因に起因しています。製造者は、既存の製品ポートフォリオをよりセキュア・バイ・デザインな実践に合わせるための書面によるロードマップを作成し、例外的な状況でのみ逸脱するようにすべきです。

執筆組織は、顧客のセキュリティ成果に責任を持ち、このレベルの顧客セキュリティを確保することが開発コストを増加させる可能性があることを認めています。しかし、革新的な技術製品を開発し、既存のものを維持しながらセキュア・バイ・デザインの実践に投資することは、顧客のセキュリティ体制を大幅に改善し、侵害の可能性を減らすことができます。セキュア・バイ・デザインの原則は、顧客のセキュリティ体制と開発者のブランド評価を強化するだけでなく、長期的には製造者の保守およびパッチ適用のコストも削減します。

以下の「ソフトウェア製造者への推奨事項」セクションでは、製造者が検討すべき製品開発の実践とポリシーのリストを提供します。

セキュア・バイ・デフォルト (Secure by Default)

「セキュア・バイ・デフォルト」とは、製品が追加費用なしで、箱から出した状態で一般的な悪用手法に対して耐性があることを意味します。これらの製品は、エンドユーザーがセキュリティを確保するために追加の手順を踏むことなく、最も一般的な脅威や脆弱性から保護します。セキュア・バイ・デフォルトな製品は、安全なデフォルトから逸脱した場合、追加の補償コントロールを実装しない限り、侵害の可能性が高まることを顧客に強く認識させるように設計されています。

セキュア・バイ・デフォルトは、セキュア・バイ・デザインの一形態です。

安全な構成がデフォルトのベースラインであるべきです。セキュア・バイ・デフォルトな製品は、悪意あるサイバー攻撃者から企業を保護するために必要な最も重要なセキュリティ制御を自動的に有効にするだけでなく、追加費用なしでセキュリティ制御を使用し、さらに構成する能力を提供します。

セキュリティ構成の複雑さは、顧客の問題であってはなりません。

組織のITスタッフは頻繁にセキュリティと運用の責任で過負荷になっており、強固なサイバーセキュリティ体制に必要なセキュリティ上の影響や緩和策を理解し実装する時間が限られています。製造者は、製品構成の最適化（「デフォルトパス」のセキュリティ確保）を通じて顧客を支援し、製品が「セキュア・バイ・デフォルト」基準に従って製造、配布、使用されることを保証できます。

「セキュア・バイ・デフォルト」な製品の製造者は、追加のセキュリティ構成を実装するために追加料金を請求しません。代わりに、すべての新車にシートベルトが含まれているように、それらを基本製品に含めます。セキュリティは贅沢なオプションではなく、交渉や追加料金なしで顧客が受け取る権利とみなされるべきです。

ソフトウェア製造者への推奨事項

この共同ガイドは、ITセキュリティを実装し確保するための書面によるロードマップを作成するための推奨事項を製造者に提供します。執筆組織は、ソフトウェア製造者が以下のセクションで概説されている戦略を実行し、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトの原則を通じて顧客のセキュリティ成果に責任を持つことを推奨します。

ソフトウェア製品セキュリティの原則

ソフトウェア製造者は、ソフトウェアセキュリティを優先する戦略的焦点を採用することが推奨されます。執筆組織は、ソフトウェア製造者が製品の開発、構成、出荷に先立つ設計プロセスにソフトウェアセキュリティを組み込むためのガイドとして、以下の3つの核心原則を策定しました。

  1. 顧客のセキュリティ成果に責任を持ち、それに応じて製品を進化させる。
    セキュリティの負担が顧客のみにかかるべきではありません。

  2. 徹底的な透明性と説明責任を受け入れる。
    ソフトウェア製造者は、安全でセキュアな製品を提供することに誇りを持ち、その能力に基づいて他の製造者コミュニティと差別化を図るべきです。これには、デフォルトでの強力な認証メカニズムの採用率など、顧客の展開から学んだ情報を共有することが含まれる場合があります。また、脆弱性アドバイザリおよび関連する共通脆弱性識別子（CVE）レコードが完全かつ正確であることを保証するための強いコミットメントも含まれます。ただし、CVEの数をネガティブな指標としてカウントしたいという誘惑には注意してください。そのような数字は、健全なコード分析とテストコミュニティの兆候でもあるからです。

  3. これらの目標を達成するための組織構造とリーダーシップを構築する。
    技術的な主題の専門知識は製品セキュリティに不可欠ですが、組織内の変革を実行するための主要な意思決定者は上級幹部です。幹部は、顧客とのパートナーシップにおいて、組織全体で製品開発の重要な要素としてセキュリティを優先する必要があります。

これら3つの原則を可能にするために、製造者は開発プロセスを進化させるためのいくつかの運用戦術を検討すべきです。

  • 企業幹部のリーダーシップとの定例会議を招集し、組織内でのセキュア・バイ・デザインおよびセキュア・バイ・デフォルトの重要性を推進する。
  • これらの原則を遵守した製品を開発した生産チームに報いるポリシーと手順を確立する（優れたソフトウェアセキュリティ実践の実装に対する表彰や、キャリアラダーおよび昇進基準へのインセンティブなど）。
  • ソフトウェアセキュリティの重要性をビジネスの成功の中心に据えて運営する。例えば、「ソフトウェアセキュリティリーダー」や「ソフトウェアセキュリティチーム」を任命し、ソフトウェアセキュリティ基準と製造者の説明責任を直接リンクさせるビジネスおよびIT慣行を維持することを検討してください。
  • 製造者は、自社製品に対して堅牢で独立した製品セキュリティ評価および評価プログラムを持つことを保証すべきです。
  • 最も重要で影響力の大きい機能を優先するために、リソース配分と開発中に調整された脅威モデルを使用する。脅威モデルは製品の特定のユースケースを考慮し、開発チームが製品を強化できるようにします。
  • 最後に、上級リーダーシップは、製品の卓越性と品質の重要な要素として、チームにセキュアな製品を提供する責任を負わせるべきです。

2023年10月の更新の一環として、これら3つの原則は、以下の説明、実証、および証拠を通じて詳しく解説されています。

※ 本記事は2023/10/25発行の version 1025 508c を基にしています。

原則1：顧客のセキュリティ成果に責任を持つ (Take Ownership of Customer Security Outcomes)

解説

現代のベストプラクティスでは、ソフトウェア製造者がアプリケーションの堅牢化（hardening）、アプリケーション機能、およびアプリケーションのデフォルト設定を含む製品セキュリティの取り組みに投資することが求められます。

ソフトウェア製造者は、アプリケーションを侵害しようとする悪意ある攻撃者のコストを引き上げるプロセスと技術を使用して、アプリケーションの堅牢化を実装する必要があります。アプリケーション堅牢化プロトコルと手順は、製品が知的な悪意ある攻撃者による攻撃に耐えるのに役立ちます。「堅牢化」、「製品セキュリティ」、「レジリエンス」といった用語はすべて製品品質と密接に関連しています。その考え方は、セキュリティは「後付け（bolted on）」ではなく「組み込まれる（baked in）」べきであるということです。 セキュリティを組み込むことで、ソフトウェア製造者は顧客のセキュリティを向上させるだけでなく、製品の品質も向上させることができます。サンプルの戦術としては、ユーザー入力が検証およびサニタイズされ、コードに直接入力されないようにすること（例：パラメータ化されたクエリを使用する）、メモリ安全なプログラミング言語を使用すること、厳格なソフトウェア開発ライフサイクル（SDLC）管理を使用すること、ハードウェアベースの暗号化キー管理を使用することなどが挙げられます。

アプリケーションは、サイバーセキュリティに関連する アプリケーション機能 をサポートする必要があります。「機能（capabilities）」と呼ばれることもあるこれらの機能は、顧客のセキュリティ体制を維持または向上させるのに役立つ方法で製品またはサービスの機能を拡張します。セキュリティ関連機能のサンプルには、すべてのネットワーク接続に対するTransport Layer Security（TLS）のサポート、シングルサインオン（SSO）のサポート、多要素認証（MFA）のサポート、セキュリティイベント監査ログ、ロールベースのアクセス制御（RBAC）、属性ベースのアクセス制御（ABAC）が含まれます。

これらの製品機能の一部は構成可能であり、顧客は製品を既存の環境やワークフローにより簡単に統合できます。これらの構成は、顧客が構成するまでアプリケーションに デフォルト設定 が必要であることを意味します。これらのデフォルト設定は、顧客が技術製品スタックをより安全にするために費やすリソースが少なくなるよう、「箱から出してすぐに」安全に設定されている必要があります。

アプリケーションの堅牢化、アプリケーションセキュリティ機能、アプリケーションのデフォルト設定というこれらの各要素は、アプリケーションのセキュリティと、その結果としての顧客のセキュリティ体制において役割を果たします。ソフトウェア製造者は、これらの各要素とそれらが互いにどのように関連しているかを考えるべきです。製造者は、これらの要素を製品に組み込むための投資以上のことを考えるべきです。製造者はさらに一歩進んで、それらの要素が良くも悪くも顧客の実際のセキュリティ体制をどのように変化させるかを考慮すべきです。

製造者は、自らの努力や投資のみで自己評価するのではなく、 顧客のセキュリティ成果に責任を持つ べきです。責任は上流、つまり製造者に置かれるべきであり、そこでこそ侵害の可能性を減らす可能性が最も高くなります。

残念ながら、今日はそうではありません。あまりにも多くの製造者が、包括的なアプリケーションの堅牢化に投資するのではなく、セキュリティの負担を顧客に負わせています。例えば、製造者が1つの脆弱性にパッチを当てた際、その欠陥の根本原因ではなく症状に対処したために、同様の脆弱性が露呈することがよくあります。製品は、同じクラスの脆弱性に対してコードベースのさまざまな部分で異なる緩和策を実装している場合があります。一例として、製造者が1つの入力サニタイズの脆弱性を修正した後、研究者や攻撃者が改善された入力サニタイズの恩恵を受けていないコードパスを発見したことがあります。製造者は、アプリケーション全体でそのクラスの脆弱性を排除するためにコードベースを統一するのではなく、一度に1つずつ修正を適用していました。

アプリケーション機能は、顧客に利益とリスクの両方をもたらす可能性があります。多くの外部システムやバージョンとの統合ポイントを可能にする機能は、製品の価値を大幅に高める可能性があります。しかし、ネットワーキングプロトコルなどの機能をリタイアメントプランなしでサポートすることは、顧客がその機能の継続使用の影響を理解していない場合、脆弱なままにする可能性があります。例えば、一部の製品は1990年代や2000年代に起源を持ち、現在では安全でないことが知られているネットワーキングプロトコルを引き続き使用しています。顧客が最新のセキュリティ対策へのアップグレードや展開を遅らせる要因は多数あります。彼らは組織のネットワークの残りの部分と統合する製品を使用しているかもしれませんが、最新のセキュリティ対策が欠けているため、ITチームが近代化できない場合があります。それでも、ソフトウェア製造者はこれらのパターンを計画プロセスに織り込み、顧客が最新の状態を維持するよう促すことができます。

アプリケーションのデフォルト設定は、顧客にとって潜在的なリスクのもう一つの領域です。製造者は特定のデフォルト設定を選択することが多く、顧客が望むアプリケーション機能を使いやすくしています。欠点は、この慣行がデフォルトで有効になっている特定の機能やプロトコルを必要としない顧客の攻撃対象領域を拡大することです。さらに、多くのセキュリティ制御はデフォルトでオフになっているか、セキュリティを強化するために顧客が時間をかけて設定を構成する必要があります。明示的な脅威モデリングは、どの機能をデフォルトでオンにすべきか、またはセキュア・バイ・デフォルトであるためにどの設定が必要かを決定するのに役立つ戦術です。別の戦術は、管理者が機能をより発見しやすくする方法を調査することです。

一部の製造者は、一部またはすべての顧客にリスクをもたらす可能性のあるデフォルト設定で製品を出荷しています。彼らは、より安全なデフォルト設定を行うのではなく、顧客が自費で実装しなければならない「堅牢化ガイド（hardening guide）」を作成することを選択することがよくあります。堅牢化ガイドにはいくつかの共通の問題があります。一部の堅牢化ガイドは見つけにくく、十分にサポートされていません。実装が複雑なものもあり、拡張モジュールを作成するためのソフトウェア開発が必要になる場合もあります。また、さまざまな設定が攻撃対象領域をどのように変化させるかを理解するために、読者が広範なサイバーセキュリティの経験を持っていることを前提としているものもあります。攻撃者がどのように機能するかを不完全にしか理解していない実務者は、特にトレードオフが明確にされていない場合、堅牢化ガイドの指示を適切に実装できない可能性があります。さらに、すべての堅牢化ガイドが攻撃者の戦術や経済性に精通したエンジニアによって書かれているわけではなく、忠実に実装されたとしても効果がない堅牢化ガイドが作成される原因となっています。何百万もの顧客が、多くの場合リソースに制約のある環境で、ソフトウェアやシステムの複数のインスタンスを堅牢化する責任を負っています。堅牢化ガイドに依存することは、単純にスケーラブルではありません。

アプリケーションの設定は、それがデフォルトであったか顧客によって設定されたかにかかわらず、製造者の現在の脅威状況に対する理解と照らし合わせて継続的に評価されるべきです。アプリケーションは、それらの設定から生じる可能性のある潜在的なリスクについての明確なインジケーター（指標）を持つように作られ、それらのインジケーターが知らされるべきです。現代の車がシートベルトに関するインジケーターを持ち、バックルを締めずに運転しようとするとアラートを鳴らしてそのインジケーターを表現するように、ソフトウェアはシステムのセキュリティ状態に関するインジケーターを表現すべきです。アプリケーションが管理者アカウントにMFAを要求しないように構成されている場合、MFAを構成しない限り、管理者および組織全体が危険にさらされていることを定期的に管理者に認識させるべきです。さらに、現在では弱い暗号化を実装していることが知られている古いプロトコルをサポートするようにアプリケーションが構成されている場合、組織が危険にさらされていることを定期的に管理者に明確にし、状況を解決するためのリソースを提供する必要があります。私たちは製造者に対し、管理者が堅牢化ガイドを解釈する時間、専門知識、認識を持っていることに依存するのではなく、製品自体に組み込まれた日常的な「ナッジ（行動を促す仕組み）」を実装することを強く求めます。セキュリティと使いやすさの考慮事項のバランスをとるためのイノベーションの余地は明らかに存在します。

上記の各要素は、顧客が侵害の可能性を減らすために追加のセキュリティ製品を調査、資金調達、購入、人員配置、展開、監視する必要があるという耐え難い状況を生み出しています。中小規模の組織（SMO）は一般的にこれらのオプションを促進することができません。彼らは専門知識、資金、時間の不足に直面しており、帯域幅と機能が圧迫され、セキュリティの優先順位が下がり、全体として集合的なリスクを悪化させています。逆に、比較的少数の製造者によるセキュリティ投資はスケール（規模拡大）します。この問題を要約する一般的なフレーズは、「ソフトウェア業界には、より多くのセキュリティ製品（security products）ではなく、より安全な製品（secure products）が必要である」というものです。ソフトウェア製造者はその変革を主導すべきです。

「ソフトウェア業界には、より多くのセキュリティ製品ではなく、より安全な製品が必要である。ソフトウェア製造者はその変革を主導すべきである。」

今日、顧客が特定のセキュリティ機能を有効にしなかった、あるいは特定の堅牢化ガイダンスに従わなかったために侵害されたと説明する製造者のコメントを目にすることがあります。その代わりに、侵害が発生した後、製造者は特定のセキュリティ機能や特定の堅牢化ガイダンスが侵害を防げたかどうかを説明し、それを追加料金なしでデフォルトにすることを検討すべきです。製品自体が設計および実装段階で十分に堅牢化されていなかった場合、製造者はそのクラスの脆弱性を製品ラインから排除するためにどのように取り組んでいるかを説明すべきです。

ソフトウェア製造者は、セキュリティを最優先事項として製品が設計および開発されることを保証する責任があります。そのために、彼らは現場での取り組みの結果を客観的に測定すべきです。私たちは製造者に対し、内部の取り組みだけに集中するのではなく、製品のセキュリティの取り組みと構成の結果と有効性を客観的に測定し定期的に報告すること、そしてSDLCに変更をもたらし、顧客の安全性とより安全な製品の測定可能な改善につながるフィードバックループを構築することを求めます。報告には、学術界やセキュリティ研究コミュニティがハイレベルな傾向を追跡し、エコシステム全体での進捗を測定するために使用できる匿名化されたデータを含めるべきです。

この原則の実証

ソフトウェア製造者およびオンラインサービスは、この原則の実装における成功を実証する方法を見つけるべきです。彼らは、外部の人間が検証できるアーティファクト（成果物）の形で証拠を提供することを目指すべきです。単一のアーティファクトだけで製造者が堅牢なセキュア・バイ・デザインプログラムを実装していることを証明することはできませんが、さまざまなアーティファクトを提供することで、製造者が安全な製品を開発することへのコミットメントの根拠を構築できます。このアプローチは、「語るのではなく、見せる（show, rather than tell）」という精神に基づいています。

この原則を実証するために、ソフトウェア製造者は以下のリストにあるようなステップを検討すべきです。執筆組織は、セキュア・バイ・デザインの旅の始まりにおいて、これらの実践を即座に実装し、対応するアーティファクトを作成できるソフトウェア製造者がほとんどいないことを認識しています。さらに、ソフトウェア製造者は、最大のセキュリティ上の利益を達成するために、顧客が現場で製品をどのように展開しているかに応じて、このリストに優先順位を付ける必要があります。

セキュア・バイ・デフォルトの実践

  1. デフォルトパスワードを排除する。
    デフォルトパスワードは、毎年多くの攻撃の原因として関与し続けています。この慢性的な問題を排除することを約束することで、攻撃者による容易なアクセスを拒否します。同様に、製造者は、最小パスワード長や既知の流出パスワードの不許可など、どのようなパスワード慣行を実装すべきかを検討すべきです。

  2. フィールドテストを実施する。
    テクノロジーが進化し複雑化するにつれて、ソフトウェア製造者がセキュリティ中心のユーザーテストを実施し、現場での製品のセキュリティ体制を理解することがますます重要になっています。ユーザーリサーチがソフトウェア開発要件に情報を提供するのと同様に、ソフトウェア製造者はセキュリティに焦点を当てたユーザーリサーチを実施し、セキュリティのユーザーエクスペリエンス（UX）がどこで不足しているかを理解すべきです。顧客が現実世界の環境で製品をどのように展開し使用しているかを観察することで、ソフトウェア製造者はセキュリティ機能と制御の使いやすさと有効性に関する貴重な洞察を得ることができます。これらの洞察は、改善すべき領域を特定し、顧客のセキュリティニーズをよりよく満たすように製品を洗練させるのに役立ちます。例えば、フィールドテストは、UXフロー、デフォルト、アラート、監視の変更を示唆するかもしれません。フィールドテストは、製品設計における過去の改善がどこでセキュリティパッチの速度を低下させ、構成エラーを減らし、攻撃対象領域を最小化したかを示す場合もあります。製造者は以下を検討すべきです：

  • 顧客は堅牢化ガイドを正しく実装しているか？
  • 製品の既存のセキュリティ機能は現場で期待通りに機能しているか？
  • それらの機能は実際に現実世界の攻撃に耐えているか？
  • どの機能が侵害の可能性をよりよく減らすか？
  • 注：これらの要素についてより深い洞察を得るために、ソフトウェア製造者は顧客と提携してレッドチーム演習を実施し、製品が攻撃にどう耐えるかを確認したいと考えるかもしれません。これらのフィールドテストは、顧客の物理的なサイトで、仮想的に、またはプライバシーを保護する方法でのアプリケーションからのテレメトリを通じて行われる可能性があります。

  1. 堅牢化ガイドのサイズを縮小する。
    製造者は、製品の堅牢化ガイドを合理化または排除し、顧客が製品を展開する際に優先すべき最も重要なセキュリティ対策に焦点を当てることで、顧客のセキュリティ体制を改善できます。顧客にセキュリティ対策の長いリストを押し付けるのではなく、製造者は製品が影響を受けやすい上位のセキュリティリスクを特定し、これらのリスクを軽減する方法に関する明確かつ簡潔なガイダンスを提供すべきです。さらに、製造者は、環境に簡単に展開できるスクリプトなど、セキュリティ制御の実装プロセスを簡素化するツールと自動化を顧客に提供すべきです。これらのツールはさらに、元のベースラインから行われた変更を検証し、明確に示すことができるべきです。堅牢化ガイドを合理化し、使いやすいツールと自動化を顧客に提供することで、製造者は顧客の負担を軽減し、製品が安全な方法で展開されることを保証するのに役立ちます。一つの戦術は、パレートの法則を実装して一般的なユースケース（80%）の手順数を減らし、あまり一般的でないシナリオ（20%）には文脈に沿ったガイダンスとツールを提供することを検討することです。このようにして、ソフトウェア製造者は「単純なことを単純に、難しいことを可能に」します。フィールドテストは、顧客が堅牢化ガイドを発見、理解、実装するのにどれくらいの時間がかかるかを測定する強力なツールになります。製造者は、管理者が堅牢化ガイドからタスクを実装することに依存するのではなく、製品自体の中で行動を起こすように製品がどのようにナッジできるかを検討すべきです。

  2. 安全でないレガシー機能の使用を積極的に阻止する。
    後方互換性よりも明確なアップグレードパスを通じてセキュリティを優先します。より安全な機能やプロトコルの採用を示すブログ投稿を公開し、アナウンスによって（場合によっては製品内から）安全でない機能を非推奨にします。かなりの数の顧客が、システムを最新のネットワーク、ID、およびその他の重要なセキュリティ機能で最新の状態に保たないことを示しています。場合によっては、顧客はアップグレードによって既存の機能が壊れることを恐れています。アップグレードを可能な限りシームレスにすることで、顧客はアップグレードを行い、セキュリティ修正をより頻繁かつ迅速に取得する可能性が高くなります。ソフトウェア製造者は、顧客のリスクを軽減するアップグレードパスに沿って顧客を積極的にナッジすべきです。

  3. 注意を引くアラートを実装する。
    シートベルトが締められていないときに継続的に音を鳴らす車のシートベルトチャイムと同様に、製造者は、ユーザーまたは管理者が真に安全でない状態にあるときに、タイムリーで繰り返されるアラートを実装し、管理者に環境で非推奨のプロトコルを使用していることを警告し、アップグレードパスを提案すべきです。ユーザーまたは管理者、あるいはアプリケーション構成が安全でない状態にある場合、タイムリーで繰り返されるアラートを実装します。安全でないモードであることを管理者に定期的に明確にします。追加機能として、ログインごとにスーパー管理者にアカウントでのMFAの欠如を認識させるか、MFAを有効にするまで特定の主要機能を無効にすることさえ必要とする可能性があります。アラート疲れを引き起こさずにこれらの目標を達成するためのイノベーションの余地があります。

  4. 安全な構成テンプレートを作成する。
    これらのテンプレートは、組織のリスク選好に基づいて特定の構成を安全な設定に事前設定できます。低/中/高セキュリティテンプレートを持つことは過度に単純化されているかもしれませんが、その例は、組織のリスクを管理するために多くの設定をどのように更新できるかを示しています。テンプレートは、製造者が特定したリスクに関する堅牢化ガイドによってサポートされます。

セキュアな製品開発の実践

  1. セキュアSDLCフレームワークへの準拠を文書化する。
    セキュアSDLCフレームワークは、人、プロセス、技術にまたがる目的と例を提供します。実装されたセキュアSDLCフレームワークのコントロールの詳細な説明を公開し、使用された代替コントロールがあれば記述することを検討してください。米国内では、NIST Secure Software Development Framework (SSDF) の使用を検討してください。チェックリストではありませんが、SSDFは「セキュアなソフトウェア開発のための基本的で健全な実践のセット」を記述しています。

  2. サイバーセキュリティパフォーマンス目標（CPG）または同等の準拠を文書化する。
    組織がNIST SSDF標準に準拠していることを証明するとき、彼らはSDLCがよく理解されたベストプラクティスに基づいていることを主張しています。しかし、堅牢なSDLCを持つだけでは十分ではありません。彼らはまた、製品がまだ開発中である間に製品のセキュリティ特性を操作しようとする悪意ある攻撃者から、自身の企業および開発環境を保護する必要があります。これは理論上の攻撃クラスではなく、顧客、ひいては国家安全保障に悪影響を及ぼす形で実行されたものです。組織は、CISA CPG、NISTサイバーセキュリティフレームワーク（CSF）、またはその他のサイバーセキュリティプログラムフレームワークへの準拠の詳細を公開することを検討すべきです。

  3. 脆弱性管理。
    一部の製造者は、内部または外部で発見された脆弱性にパッチを当てることに焦点を当て、それ以上のことをほとんど行わない脆弱性管理プログラムを持っています。より成熟したプログラムは、脆弱性とその根本原因の広範なデータ駆動型分析を取り入れ、脆弱性のクラス全体を体系的に排除するための措置を講じます。彼らは、品質計画、品質管理、品質改善、品質測定の設定に関する正式なプログラムを実装します。彼らは欠陥管理を単なるセキュリティの問題ではなく、ビジネスの問題と見なしています。これらのプログラムは、他の産業における品質および安全プログラムといくつかの点で似ています。

  4. オープンソースソフトウェアを責任を持って使用する。
    オープンソースソフトウェアを使用する場合、オープンソースパッケージを精査し、依存関係へのコード貢献を促進し、重要なコンポーネントの開発と保守の維持を支援することで責任を果たしてください。参考として、日本の経済産業省（METI）は「OSSの利活用及びそのセキュリティ確保に向けた管理手法に関する事例集」を公開しています。

  5. 開発者に安全なデフォルトを提供する。
    開発者に安全なビルディングブロックを提供することで、ソフトウェア開発中のデフォルトルートを安全なものにします。例えば、SQLインジェクション脆弱性が現実世界で害を及ぼしていることの蔓延を考慮し、開発者がそのクラスの脆弱性を防ぐためによく保守されたライブラリを使用するようにします。「舗装された道路（paved roads）」または「明るい道（well-lit paths）」としても知られるこの実践は、スピードとセキュリティの両方を確保し、人的ミスを減らします。

  6. セキュリティを理解するソフトウェア開発者要員を育成する。
    セキュアコーディングのベストプラクティスについてトレーニングすることで、ソフトウェア開発者がセキュリティを理解するようにします。さらに、セキュリティ知識を評価するための採用慣行を更新し、大学、コミュニティカレッジ、ブートキャンプ、その他の教育者と協力して、コンピュータサイエンスおよびソフトウェア開発のカリキュラムにセキュリティを織り込むことで、より広範な労働力を変革するのを支援します。

  7. セキュリティ情報イベント管理（SIEM）およびセキュリティオーケストレーション、自動化、応答（SOAR）の統合をテストする。
    フィールドテストの実施に加えて、人気のSIEMおよびSOARプロバイダーと、一部の顧客と共同で作業し、インシデント対応チームが疑わしいまたは実際のセキュリティインシデントを調査するためにログをどのように使用するかを理解します。インシデントへの対応経験を持つソフトウェア開発者は少なく、対応者が期待するほど役立たないログエントリを作成する可能性があります。SIEMおよびSOARテクノロジーと実際のインシデント対応専門家の両方と協力することで、開発チームは正確で完全なストーリーを語るログを作成し、インシデント中の時間を節約し、不確実性を減らすことができます。

  8. ゼロトラストアーキテクチャ（ZTA）との整合。
    製品展開ガイドを、例えばNIST ZTAモデルやCISAゼロトラスト成熟度モデルに合わせて調整します。顧客がこれらの原則を環境に組み込むことを奨励します。

プロセキュリティ（セキュリティ重視）なビジネス慣行

  1. 追加料金なしでログを提供する。
    クラウドサービスは、セキュリティ関連のログを追加料金なしで生成および保存することを約束すべきです。オンプレミス製品も同様に、追加料金なしでセキュリティ関連のログを生成すべきです。さらに、多くの顧客はインシデントが発生するまでその価値を理解しない可能性があるため、製品はデフォルトでセキュリティイベントをログに記録すべきです。これらの戦術には、サイバーセキュリティ状態の認識を提供するためにどのセキュリティイベントをログに記録すべきか、顧客がログ記録をどのように構成できるか、ログが保持される期間、ログの整合性とストレージがどのように保護されるか、ログをどのように分析できるかについての徹底的なレビューが必要になる場合があります。場合によっては、レビューにより、ログを実行可能にし、かつ製造者にとって機能するコストにするために、アプリケーションのログ管理アーキテクチャのリファクタリングの必要性が示唆されるかもしれません。インシデント対応（IR）の専門家と協力することで、ログが現場の調査員にとって役立つ可能性を高めることができます。SIEMに関するセクションを参照してください。

  2. 隠れた税金を排除する。
    セキュリティまたはプライバシー機能や統合に対して決して料金を請求しないというコミットメントを公開してください。例えば、IDおよびアクセス管理（IAM）の大きな範囲内で、シングルサインオン（SSO）サービスと呼ばれるサービスがあります。一部の製造者は、システムをSSOサービス（アイデンティティプロバイダと呼ばれることもある）に接続するためにより多くを請求します。この「SSO税」は、優れたIDおよびアクセス管理が多くのSMO（中小規模組織）の手の届かないところにあり、彼らが強力なセキュリティ体制を達成するのを妨げていることを意味します。一部のサービスは、ユーザーのMFAを有効にするためにより多くを請求します。セキュリティは贅沢品として価格設定されるべきではなく、顧客の権利と見なされるべきです。一部の製造者は、これらの機能を要求する顧客は少なく、維持にコストがかかると主張しています。これらの議論は、不平を言ったり交渉したりする顧客はほとんどいないこと、すべての顧客がこれらの機能の利点を実際に理解しているわけではないこと、すべての機能の維持にはコストがかかるという事実を無視しています。しかし、可用性やデータの整合性のために追加料金を請求する製造者はあまり見かけません。これらの重要な属性をサポートするコストは、事故で命を救うシートベルト、衝撃吸収ステアリングコラム、エアバッグを含めるコストと同様に、すべての顧客が支払う価格に組み込まれています。

  3. オープンスタンダードを受け入れる。
    特に一般的なネットワークおよびIDプロトコル周辺で、オープンスタンダードを実装してください。オープンスタンダードが利用可能な場合は、独自のプロトコルを避けてください。

  4. アップグレードツールを提供する。
    多くの顧客は、安全なネットワーク接続などの新しくより安全な機能の展開を含め、製品の最新バージョンの採用に消極的です。ソフトウェア製造者は、不確実性とリスクを軽減するのに役立つツールを提供することで、顧客による新しいアップグレードの採用を増やすことができます。顧客を動機付ける方法として、テスト環境でアップグレードとパッチをテストするための無料ライセンスを提供してください。

原則2：徹底的な透明性と説明責任を受け入れる (Embrace Radical Transparency and Accountability)

解説

ソフトウェア製造者は、安全でセキュアな製品を提供することに誇りを持ち、その能力に基づいて他の製造者コミュニティと差別化を図るべきです。

透明性に関する一般的な懸念に対処しましょう。実務者が徹底的な透明性について議論するとき、会話が「攻撃者にロードマップを提供している」という懸念に行き詰まる傾向があります。しかし、圧倒的な証拠は、攻撃者はそのようなロードマップがなくてもうまくやっていることを示しており、そのような懸念は、直接の顧客、間接的な顧客、サプライチェーン、およびソフトウェア業界全体に利益をもたらす透明性よりも後回しにされるべきです。

透明性は、業界が慣習（言い換えれば、「良い」とはどのようなものか）を確立するのに役立ちます。それは、顧客のニーズ、脅威アクターの戦術や経済性の変化、または技術の進化に応じて、それらの慣習が時間の経過とともに変化するのを助けます。透明性は、リソースの少ない製造者が、より成熟し能力のあるリソースを持つ製造者から学ぶのを助けます。情報共有に関する会話は、リアルタイムの脅威インジケーターを超えて、以下の要素を含むように拡大すべきです。透明性は、セキュリティに関する決定を開発プロセスの早い段階で行うことを強制し、エンジニアやセキュリティ専門家だけでなく、ビジネスリーダーの継続的な活動となるようにします。透明性は製品に説明責任を組み込みます。

「徹底的（radical）」という形容詞の選択についての注記：今日、ソフトウェア製造者がソフトウェアの開発と保守の方法、およびデータを時間の経過とともに使用してプログラムをどのように成熟させているかについての詳細な情報を公開することは珍しいことです。ソフトウェア業界では、ソフトウェアの設計方法のガイド付きツアーを提供する製造者はほとんどいません。ソフトウェア製造者が、同業他社がSDLCプログラムをどのように構成しているか、そしてそれらのプログラムが実際の攻撃者に対して顧客環境でどのように持ちこたえているかを見る機会はほとんどありません。

業界全体として、セキュリティ欠陥のコストを測定し、脆弱性のクラスを排除するための戦略などのトピックに関する情報共有が増えることで利益を得るでしょう。これらの一般的な慣行の結果として、すべてのソフトウェア製造者は独自に製品セキュリティに対処する方法を学ばなければなりません。おそらく、セキュリティ機能に贅沢税を課さないことで、安全性とセキュリティは利益センターではなくコストセンターになり、企業はコラボレーションと透明性を通じて負荷を軽減することで利益を得るでしょう。

私たちは、ソフトウェア業界の進化を実質的に加速させる戦術に焦点を当てたいと考えています。私たちはもはや、日和見的で漸進的な改善を行う余裕はありません。私たちが集合的に、知的で適応性のある敵対者によってもたらされる脅威を克服するためには、今日では不快に感じるかもしれないが、業界を前進させるレベルの透明性を受け入れなければなりません。

これらのセキュア・バイ・デザイン原則の一部を体現している製造者は今日存在します。ウィリアム・ギブソンが言ったように、「未来はすでにここにある。ただ、均等に分配されていないだけだ」。徹底的な透明性はその情報を分配し、敵対者よりも防御者に利益をもたらすでしょう。

透明性は、同業他社がSDLCを成熟させるのを助ける以上のことができます。見込み客や投資家は、製造者が行った投資とトレードオフ、およびそれらの投資が顧客のために作成したセキュリティ体制について詳しく学ぶことができます。徹底的な透明性を受け入れる製造者は、価格や機能だけでなく、セキュリティに基づいて購入決定を行うための情報を顧客に提供します。

組織がサプライチェーンとSDLCを保護するためにどれほど懸命に取り組んでも、過去にビルドプロセスが侵害された企業があります。徹底的な透明性を受け入れることは、攻撃の公表だけでなく、将来の攻撃を防ぎ検出するために会社が行った改善の公表にもつながるはずです。その形の情報共有は、他の組織が同じ運命をたどることなく学ぶのに役立ちます。

この原則の実証

この原則を実証するために、ソフトウェア製造者は以下のステップを含む措置を講じるべきです。

セキュア・バイ・デフォルトの実践

  1. 集計されたセキュリティ関連の統計と傾向を公開する。 例としては、顧客と管理者によるMFAの採用、安全でないレガシープロトコルの使用などがあります。
  2. パッチ適用統計を公開する。 顧客の何パーセントが製品の最新バージョンを使用しているか、および更新をより簡単かつ信頼性の高いものにするために何をしているかを詳しく説明します。
  3. 未使用の特権に関するデータを公開する。 顧客ベース全体での過剰な権限に関する集計情報と、顧客の攻撃対象領域を減らすために行っている製品へのナッジやその他の変更を公開します。これらの未使用の特権は、シートベルトチャイムのような管理者アラートの良い候補になる可能性があります。

セキュアな製品開発の実践

  1. 内部セキュリティ統制を確立する。
    多くの企業がデータをクラウドプロバイダーに移行することの利点を見てきました。今、それらのクラウドプロバイダーが攻撃者の標的になっています。SaaS（Software as a Service）プロバイダーは、内部統制の統計を公開すべきです。例えば、SaaSプロバイダーは、Fast Identity Online（FIDO）認証のようなフィッシング耐性のあるMFAの内部展開に関する統計を公開すべきです。理想的には、フィッシング耐性のあるMFAによる認証なしでは、スタッフメンバーが顧客やその他の機密データにアクセスできないと言えるようにすべきです。

  2. ハイレベルな脅威モデルを公開する。
    セキュア・バイ・デザインな製品は、作成者が何を誰から保護しようとしているのかを説明する書面による脅威モデルから始まります。効果的な脅威モデルは、野生（実社会）で侵入が発生する方法によって情報が提供され、企業および開発環境の両方と、ソフトウェア製造者が顧客環境で使用されることを意図している方法をカバーすべきです。

  3. 詳細なセキュアSDLC自己証明を公開する。 NIST SSDFまたは他の同様のフレームワークに従っている製造者は、成熟したソフトウェア開発ライフサイクルに向けて積極的に取り組んでいます。製造者がどのコントロールを制定したか、どの製品についてかを自己証明して公開することは、これらのベストプラクティスを遵守することへのコミットメントを示し、顧客への信頼レベルを高めるでしょう。他の認証スキームには、例えばイスラエルのサイバーサプライチェーン方法論が含まれます。

  4. 脆弱性の透明性を受け入れる。
    特定された製品の脆弱性が、正確かつ完全なCVEエントリとして公開されることを保証するコミットメントを公開してください。これは、脆弱性の根本原因を特定する共通脆弱性タイプ一覧（CWE）フィールドについて特に当てはまります。公開CVEデータベースが正確で完全であればあるほど、業界は製品がどのように安全になっているか、どのクラスの脆弱性が最も一般的であるかを追跡できます。ただし、CVEの数をネガティブな指標としてカウントしたいという誘惑には注意してください。そのような数字は、健全なコード分析とテストコミュニティの兆候でもあるからです。製造者がセキュア・バイ・デザインの哲学を実装するにつれて、既存のコード内の脆弱性のより包括的な発見と修正により、最初は生のCVEカウントが増加する可能性があります。製造者は、パターンや脆弱性のクラス全体に対処するために講じられた措置を含む、過去の脆弱性の分析を公開すべきです。例えば、企業のCVEの大部分がクロスサイトスクリプティング（XSS）に関連していた場合、根本原因分析、対応（XSSを防ぐWebテンプレートフレームワークへの移行など）、および結果を文書化することで、緩和策が何十年も前から理解されている脆弱性のクラスの犠牲にならないことを顧客に伝えることができます。

  5. ソフトウェア部品表（SBOM）を公開する。
    製造者はサプライチェーンを掌握しているべきです。組織は、各製品のSBOMを構築および維持し、サプライヤーにデータを要求し、下流の顧客やユーザーがSBOMを利用できるようにすべきです。これは、製品の作成に使用するコンポーネントを理解する上での勤勉さ、新たに特定されたリスクに対応する能力を示すのに役立ち、サプライチェーン内のモジュールの1つに新しく発見された脆弱性がある場合、顧客がどのように対応すべきかを理解するのに役立ちます。参考として、日本の経済産業省（METI）は「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引」を公開しています。
    透明性は、組み込みデバイスのファームウェアやAI/機械学習（ML）で使用されるデータとモデルにも拡張されるべきです。購入決定や運用能力を支援するだけでなく、SBOMは悪意あるサプライチェーン攻撃を検出して対応するためのインフラストラクチャにおいて重要な役割を果たします。

  6. 脆弱性開示ポリシーを公開する。
    (1) 製造者が提供するすべての製品に対するテストとそれらのテストの条件を許可し
    (2) ポリシーと一致して実行されたアクションに対する法的セーフハーバーを提供し
    (3) 設定されたタイムライン後に脆弱性の公表を許可する脆弱性開示ポリシーを公開してください。
    製造者は、発見された脆弱性の根本原因分析を実行し、実行可能な限り、脆弱性クラス全体を排除するためのアクションを実行すべきです。参考言語については、CISAの脆弱性開示ポリシーテンプレートを参照してください。

プロセキュリティなビジネス慣行

  1. セキュア・バイ・デザインの上級幹部スポンサーを公に指名する。
    多くの組織では、セキュリティ（品質と同様に）は技術チームに委任されており、製品のセキュリティを劇的に改善するために構造的な変更を行う能力は限られています。セキュア・バイ・デザインプログラムを監督するトップビジネス幹部を公に指名することで、製品のセキュリティをトップレベルのビジネス上の懸念に変えることができます。

  2. セキュア・バイ・デザインロードマップを公開する。
    製造者は、フィールドテストレポート、脆弱性のクラス全体を排除するために講じられたアクション、および他の原則に記載されているその他の項目に関する詳細を含め、顧客のセキュリティを改善するためにSDLCに加えられた変更を文書化すべきです。品質改善の取り組みの場合と同様に、セキュリティ改善プログラムには、計画、管理、改善の明確な段階があります。「語るのではなく見せる」という精神で、ロードマップとこれらの段階の背後にある詳細を公開することで、製品がセキュア・バイ・デザインであるという信頼を築くことができます。有意義な進歩を達成した後、製造者は透明性レポートでそれらを詳述できます。そうすることで、セキュア・バイ・デザインの原則へのコミットメントを示すだけでなく、実存証明を示すことで、他の人々が同様のプログラムを採用するように促すことができます。

  3. メモリ安全性ロードマップを公開する。
    製造者は、既存の製品を移行し、メモリ安全な言語を使用して新製品を構築することで、最大級の脆弱性クラスの1つを排除するための措置を講じることができます。すべての場合においてこれが可能ではないかもしれませんが、製造者はアプリケーション全体を書き直す代わりに、メモリ安全な言語でアプリケーションラッパーを開発することを検討できます。これには、製造者が採用、トレーニング、コードレビュー、その他の内部プロセスをどのように更新しているか、およびオープンソースコミュニティが同じことを行うのをどのように支援しているかも含まれます。

  4. 結果を公開する。
    セキュア・バイ・デザインの哲学を体現するようにSDLCを更新している間、組織は迅速な勝利、よりリソース集約的な勝利、およびいくつかの予期せぬ後退を見つけるでしょう。内部の成功と障害を提示することで、業界全体がその結果から学ぶことができます。

原則3：トップが主導する (Lead from the Top)

解説

全体的な哲学は「セキュア・バイ・デザイン」と呼ばれていますが、顧客の安全に対するインセンティブは、製品設計フェーズのかなり前から始まります。それらはビジネスの目標と、暗黙的および明示的な目的と望ましい成果から始まります。シニアリーダーがセキュリティをビジネスの優先事項とし、内部インセンティブを作成し、セキュリティを設計要件にするための全社的な文化を醸成した場合にのみ、最良の結果を達成できます。

技術的な主題の専門知識は製品セキュリティに不可欠ですが、技術スタッフだけに任せることができる問題ではありません。それはトップから始めなければならないビジネスの優先事項です。

ソフトウェア製造者が最初の2つの原則を受け入れ、有意義なアーティファクトを作成している場合、3番目の原則は必要か疑問に思う人もいるかもしれません。企業がビジョン、ミッション、価値観、文化をどのように確立するかは製品に影響を与え、それらの要素はトップに大きな要素を持っています。私たちは、安全性と品質を劇的に改善した他の業界でこれを見ています。著名な品質専門家J.M.ジュランは次のように書いています。

「品質のリーダーシップの達成には、上級管理職が個人的に品質管理を担当する必要があります。品質のリーダーシップを達成した企業では、上級管理職が個人的にイニシアチブを指導しました。私は例外を知りません。」(Juran on Quality by Design by J.M. Juran, 1992)

私たちは、セキュリティは製品品質のサブカテゴリであると信じています。セキュリティと品質が技術スタッフだけに任された技術的機能ではなく、ビジネス上の必須事項になると、組織は顧客のセキュリティニーズにより迅速かつ効率的に対応できるようになります。さらに、ソフトウェアセキュリティが最初から中核的なビジネス優先事項であることを保証するために必要なリソースを投資することで、ソフトウェアの欠陥に対処する長期的なコストが削減され、ひいては国家安全保障のリスクが低下します。

リーダーシップチームが企業の社会的責任（CSR）プログラムを実施してきたのと同様に、ソフトウェア製造者を含む企業の取締役会は、サイバーセキュリティプログラムの指導においてより積極的な役割を果たすべきであるという認識が高まっています。「企業のサイバー責任（CCR）」という用語は、この新たな考え方を表すために使用されることがあります。

この原則の実証

この原則を実証するために、ソフトウェア製造者は以下のステップを含む措置を講じるべきです。

  1. 企業の財務報告書にセキュア・バイ・デザインプログラムの詳細を含める。
    製造者が上場企業である場合、各年次報告書にセキュア・バイ・デザインの取り組みに特化したセクションを追加します。自動車の年次財務報告書には、ドライバーと乗客の安全に関するセクションが含まれ、集中型および分散型の品質および安全委員会に関する情報が含まれるのが一般的です。財務報告書でセキュア・バイ・デザインプログラムを詳述することは、組織が顧客のセキュリティと企業の財務成果を結びつけており、単に流行っているからという理由でマーケティング資料に用語を採用しているのではないことを示します。

  2. 取締役会に定期的な報告を提供する。
    最高情報セキュリティ責任者（CISO）による取締役会への報告には通常、現在および計画中のセキュリティプログラム、脅威、疑わしいおよび確認されたセキュリティインシデント、および会社のセキュリティ体制と健全性を中心としたその他の更新に関する情報が含まれます。企業のセキュリティ体制に関する情報を受け取ることに加えて、取締役会は製品セキュリティとそれが顧客のセキュリティに与える影響に関する情報を要求すべきです。取締役会はCISOだけを見るのではなく、主に他の経営陣メンバーを見て、顧客のリスクを下げるように推進すべきです。

  3. セキュア・バイ・デザイン担当役員に権限を与える。
    技術チームが「役員の賛同（buy-in）」を得ている組織と、ビジネスリーダーが標準的なビジネスプロセスを使用して顧客の安全性向上プロセスを個人的に管理している組織との間には大きな違いがあります。「役員の賛同」という用語は、顧客安全プログラムがトップレベルのビジネス目標であるというよりも、誰かがそのアイデアを売り込まなければならなかったことを示唆しています。この役員は、顧客のセキュリティ成果を達成するために製品投資に影響を与える権限を与えられなければなりません。

  4. 有意義な内部インセンティブを作成する。
    逆インセンティブを作成しないように注意しながら、顧客のセキュリティを向上させるための報酬システムを、他の評価される行動や成果と一致させます。セキュア・バイ・デザイン担当役員から製品管理、ソフトウェア開発、サポート、販売、法務、およびその他の組織に至るまで、採用、昇進、給与、ボーナス、ストックオプション、およびビジネス運営のその他の一般的なプロセスに顧客セキュリティインセンティブを織り込みます。例えば、ソフトウェア開発者の昇進基準を確立する際には、稼働時間、パフォーマンス、機能改善などの他の基準とともに、製品のセキュリティ向上に関する考慮事項を含めます。

  5. セキュア・バイ・デザイン評議会を作成する。
    一部の業界では、組織が中央品質評議会を作成し、主要な部門やビジネスユニットに品質担当者を配置することが一般的です。集中型メンバーと分散型メンバーの両方を含めることで、これらのグループはトップレベルの目標に対して品質を向上させるよう取り組みながら、組織の深部からテレメトリを受け取ります。同様に、セキュア・バイ・デザイン評議会は、組織全体でセキュア・バイ・デザインの目標に対してセキュリティを向上させます。

  6. 顧客評議会を作成し進化させる。
    多くのソフトウェア製造者は、さまざまな地域、業界、規模の顧客で構成される顧客評議会を持っています。これらの評議会は、顧客の成功と会社の製品を展開する際の課題について多くの情報を提供できます。参加者にとって現在最優先事項でない場合でも、顧客の安全性に対処する専用のトピックで評議会のアジェンダを構成します。顧客評議会がどこに報告するか、そして製品のセキュリティが展開された状態で洞察を得るために参加者をどのように活用するかを検討してください。例えば、評議会はマーケティングや販売目的、または製品管理に偏りがありますか？セキュア・バイ・デザイン担当役員は、これらの顧客とのやり取りを主導するのを助け、フィールドスタディなど、本書の他の要素とリンクさせるべきです。

セキュア・バイ・デザインの戦術

セキュアソフトウェア開発フレームワーク（SSDF）、別名NIST SP 800-218は、ソフトウェア開発ライフサイクル（SDLC）の各段階に統合できる、高レベルのセキュアソフトウェア開発実践のコアセットです。これらの実践に従うことで、ソフトウェア生産者はリリースされたソフトウェアの脆弱性を発見して削除するのにより効果的になり、脆弱性の悪用の潜在的な影響を軽減し、将来の再発を防ぐために脆弱性の根本原因に対処することができます。

執筆組織は、SSDFの実践を参照する原則を含む、セキュア・バイ・デザインの戦術の使用を奨励します。ソフトウェア製造者は、ポートフォリオ全体でよりセキュア・バイ・デザインなソフトウェア開発実践を採用するための書面によるロードマップを作成すべきです。

以下は、ロードマップのベストプラクティスの非網羅的な例示リストです。

  • メモリ安全なプログラミング言語 (SSDF PW.6.1):
    可能な限りメモリ安全な言語の使用を優先してください。執筆組織は、メモリ固有の緩和策がレガシーコードベースの短期的な戦術として役立つ可能性があることを認めています。例としては、C/C++言語の改善、ハードウェア緩和策、アドレス空間配置のランダム化（ASLR）、制御フロー整合性（CFI）、およびファジングが含まれます。それにもかかわらず、メモリ安全なプログラミング言語の採用がこのクラスの欠陥を排除できるというコンセンサスが高まっており、ソフトウェア製造者はそれらを採用する方法を探るべきです。現代のメモリ安全な言語の例には、C#、Rust、Ruby、Java、Go、Swiftなどがあります。詳細はNSAのメモリ安全性情報シートを読んでください。

  • セキュアハードウェア基盤:
    従来のハードウェア命令セットアーキテクチャ（ISA）を拡張できるCapability Hardware Enhanced RISC Instructions (CHERI) によって記述されるような、きめ細かいメモリ保護を可能にするアーキテクチャ機能、およびTrusted Platform ModulesやHardware Security Modulesなどの他の機能を組み込みます。詳細については、ケンブリッジ大学のCHERIウェブページをご覧ください。

  • セキュアなソフトウェアコンポーネント (SSDF PW 4.1):
    検証済みの商用、オープンソース、およびその他のサードパーティ開発者から、十分に保護されたソフトウェアコンポーネント（例：ソフトウェアライブラリ、モジュール、ミドルウェア、フレームワーク）を取得および維持し、消費者向けソフトウェア製品の堅牢なセキュリティを確保します。

  • Webテンプレートフレームワーク (SSDF PW.5.1):
    クロスサイトスクリプティングなどのWeb攻撃を回避するために、ユーザー入力の自動エスケープを実装するWebテンプレートフレームワークを使用します。

  • パラメータ化されたクエリ (SSDF PW 5.1): SQLインジェクション攻撃を回避するために、クエリにユーザー入力を含めるのではなく、パラメータ化されたクエリを使用します。

  • 静的および動的アプリケーションセキュリティテスト (SAST/DAST) (SSDF PW.7.2, PW.8.2):
    これらのツールを使用して、製品のソースコードとアプリケーションの動作を分析し、エラーが発生しやすい慣行を検出します。これらのツールは、不適切なメモリ管理からエラーが発生しやすいデータベースクエリ構築（例：SQLインジェクションにつながるエスケープされていないユーザー入力）まで、さまざまな問題をカバーします。SASTおよびDASTツールは開発プロセスに組み込み、ソフトウェア開発の一部として自動的に実行できます。SASTおよびDASTは、ユニットテストや統合テストなどの他の種類のテストを補完し、製品が期待されるセキュリティ要件に準拠していることを確認すべきです。問題が特定された場合、製造者は脆弱性に体系的に対処するために根本原因分析を実行すべきです。

  • コードレビュー (SSDF PW.7.1, PW.7.2):
    製品に提出されたコードが、他の開発者によるピアレビューや「エラーシーディング」などの品質管理手法を確実に通過するように努めます。

  • ソフトウェア部品表 (SBOM) (SSDF PS.3.2, PW.4.1):
    製品に入るソフトウェアのセットへの可視性を提供するために、SBOMの作成を組み込みます。

  • 脆弱性開示プログラム (SSDF RV.1.3):
    セキュリティ研究者が脆弱性を報告し、そうすることで法的セーフハーバーを受け取れるようにする脆弱性開示プログラムを確立します。これの一環として、サプライヤーは発見された脆弱性の根本原因を特定するプロセスを確立すべきです。そのようなプロセスには、本書のセキュア・バイ・デザインの実践（または他の同様の実践）を採用していれば、脆弱性の導入を防げたかどうかを判断することを含めるべきです。

  • CVEの完全性:
    公開されたCVEに根本原因または共通脆弱性タイプ一覧（CWE）が含まれていることを確認し、ソフトウェアセキュリティ設計上の欠陥の業界全体での分析を可能にします。すべてのCVEが正確で完全であることを確認するには余分な時間がかかる場合がありますが、それにより、すべての製造者と顧客に利益をもたらす業界の傾向を異なるエンティティが発見できるようになります。脆弱性の管理に関する詳細については、CISAのStakeholder Specific Vulnerability Categorization (SSVC) ガイダンスを参照してください。

  • 多層防御 (Defense-in-Depth):
    単一のセキュリティ制御の侵害がシステム全体の侵害につながらないようにインフラストラクチャを設計します。例えば、ユーザー特権が狭くプロビジョニングされ、アクセス制御リストが採用されていることを確認することで、侵害されたアカウントの影響を減らすことができます。また、ソフトウェアサンドボックス技術は、脆弱性を隔離してアプリケーション全体の侵害を制限できます。

  • サイバーセキュリティパフォーマンス目標 (CPGs) を満たす:
    基本的なセキュリティ慣行を満たす製品を設計します。CISAのサイバーセキュリティパフォーマンス目標は、組織が実装すべき基本的でベースラインとなるサイバーセキュリティ対策を概説しています。さらに、組織の体制を強化するその他の方法については、CISAのCPGと類似点があるNCSC-UKのサイバー評価フレームワークを参照してください。製造者がCPGを満たしていない場合（例えば、全従業員にフィッシング耐性のあるMFAを要求していないなど）、セキュア・バイ・デザインな製品を提供しているとは見なされません。

執筆組織は、これらの変更が組織の体制における重要なシフトであることを認識しています。したがって、それらの導入は、調整された脅威モデリング、重要性、複雑さ、およびビジネスへの影響に基づいて優先順位付けされるべきです。これらの実践は、新しいソフトウェアに導入し、追加のユースケースや製品をカバーするように段階的に拡張できます。場合によっては、特定の製品の重要性とリスクの状況により、これらの実践を採用するためのスケジュールを加速するメリットがあるかもしれません。また、レガシーコードベースに実践を導入し、時間の経過とともに修正することもできます。

セキュア・バイ・デフォルトの戦術

セキュア・バイ・デザイン開発の実践を採用することに加えて、執筆組織は、ソフトウェア製造者が製品においてセキュア・バイ・デフォルト構成を優先することを推奨します。これらは、製品が更新される際にこれらの実践に準拠するように努めるべきです。例えば：

  • デフォルトパスワードを排除する。
    製品は、普遍的に共有されるデフォルトパスワードが付いてくるべきではありません。デフォルトパスワードを排除するために、執筆組織は、インストールおよび構成中に管理者に強力なパスワードを設定させるか、各デバイスに固有の強力なパスワードを出荷することを製品に要求することを推奨します。

  • 特権ユーザーに多要素認証 (MFA) を義務付ける。
    私たちは、多くのエンタープライズ展開が、アカウントをMFAで保護していない管理者によって管理されていることを観察しています。管理者が高価値のターゲットであることを考えると、製品はMFAをオプトイン（選択制）ではなくオプトアウト（拒否しない限り適用）にすべきです。さらに、システムは、管理者がアカウントでMFAを正常に有効にするまで、定期的に登録を促すべきです。オランダのNCSCにはCISAと同様のガイダンスがあります。詳細については、Mature Authentication Factsheetを参照してください。

  • シングルサインオン (SSO)。
    ITアプリケーションは、最新のオープンスタンダードを介してシングルサインオンサポートを実装すべきです。例としては、Security Assertion Markup Language (SAML) や OpenID Connect (OIDC) があります。この機能は、追加費用なしでデフォルトで利用可能であるべきです。

  • セキュアなログ記録。
    高品質の監査ログを追加料金や追加構成なしで顧客に提供します。監査ログは、潜在的なセキュリティインシデントの検出とエスカレーションに不可欠です。また、疑わしいまたは確認されたセキュリティインシデントの調査中にも不可欠です。協定世界時（UTC）、標準タイムゾーン形式、および堅牢な文書化技術を使用するアプリケーションプログラミングインターフェース（API）アクセスを備えたセキュリティ情報イベント管理（SIEM）システムとの容易な統合を提供するなどのベストプラクティスを検討してください。

  • ソフトウェア認証プロファイル。
    ソフトウェアサプライヤーは、承認されたプロファイルの役割とその指定されたユースケースに関する推奨事項を提供すべきです。製造者は、推奨されるプロファイル認証から逸脱した場合のリスク増加を顧客に通知する目に見える警告を含めるべきです。例えば、医師はすべての患者記録を閲覧できますが、医療スケジューラーは予約のスケジュールに必要な特定の情報へのアクセスのみに制限されます。

  • 後方互換性よりも将来を見据えたセキュリティ。
    あまりにも頻繁に、後方互換性のあるレガシー機能が製品に含まれ、多くの場合有効になっており、製品のセキュリティにリスクをもたらしています。後方互換性よりもセキュリティを優先し、たとえ破壊的な変更を引き起こすことを意味するとしても、セキュリティチームが安全でない機能を削除する権限を与えます。

  • 「堅牢化ガイド」のサイズを追跡し削減する。
    製品に含まれる「堅牢化ガイド」のサイズを削減し、ソフトウェアの新しいバージョンがリリースされるにつれてサイズが縮小するように努めます。「堅牢化ガイド」のコンポーネントを製品のデフォルト構成として統合します。執筆組織は、短縮された堅牢化ガイドが既存の顧客との継続的なパートナーシップから生じ、ユーザーエクスペリエンス（UX）を含む多くの製品チームによる努力を含むことを認識しています。

  • セキュリティ設定のユーザーエクスペリエンスへの影響を考慮する。
    新しい設定はそれぞれエンドユーザーの認知負担を増加させるため、それがもたらすビジネス上の利益と併せて評価されるべきです。理想的には、設定は存在すべきではありません。代わりに、最も安全な設定がデフォルトで製品に統合されるべきです。構成が必要な場合、デフォルトのオプションは一般的な脅威に対して広く安全であるべきです。

執筆組織は、これらの変更がソフトウェアの採用方法に運用上の影響を与える可能性があることを認めています。したがって、運用とセキュリティの考慮事項のバランスをとる上で、顧客の入力が重要です。私たちは、組織の最も重要な製品にこれらのアイデアを優先する書面によるロードマップと経営幹部のサポートを開発することが、セキュアなソフトウェア開発の実践にシフトするための第一歩であると信じています。顧客の入力は重要ですが、顧客が改善された標準（多くの場合ネットワークプロトコル）を採用する意思がないか、できない重要なケースを観察してきました。製造者にとって、顧客が最新の状態を維持し、無期限に脆弱なままにならないようにするための有意義なインセンティブを作成することが重要です。

堅牢化ガイド vs 緩和ガイド (Hardening vs Loosening Guides)

堅牢化ガイドは、製品のセキュリティ制御が開発の開始から製品のアーキテクチャに埋め込まれていないことに起因する場合があります。その結果、堅牢化ガイドは、敵対者が安全でない機能を特定して悪用するためのロードマップになる可能性もあります。多くの組織が堅牢化ガイドの存在を知らないのが一般的であり、その結果、デバイス構成設定を安全でない状態のままにしています。

そのような堅牢化ガイドに代わって、「緩和ガイド（loosening guide）」と呼ばれる逆のモデルを採用すべきです。これは、ユーザーが行うべき変更を説明すると同時に、結果として生じるセキュリティリスクをリストアップするものです。これらのガイドは、明確な言葉でトレードオフを説明できるセキュリティ実務者によって書かれるべきであり、それらが正しく適用される可能性を高めます。

執筆組織は、製品を保護する方法をリストアップした堅牢化ガイドを開発するのではなく、ソフトウェア製造者がセキュア・バイ・デフォルトのアプローチにシフトし、「緩和ガイド」を提供することを推奨します。これらのガイドは、平易で理解しやすい言葉で決定のビジネスリスクを説明し、悪意あるサイバー侵入に対するリスクへの組織的な認識を高めることができます。セキュリティのトレードオフは、セキュリティと他のビジネス要件とのバランスを取りながら、顧客の上級幹部によって決定されるべきです。

顧客への推奨事項

執筆組織は、組織が供給元のソフトウェア製造者に対し、製品のセキュリティ成果について責任を問うことを推奨します。これの一環として、執筆組織は、経営幹部がセキュア・バイ・デザインおよびセキュア・バイ・デフォルトな製品を購入することの重要性を優先することを推奨します。

これは、IT部門が購入前にソフトウェアのセキュリティを評価することを義務付けるポリシーを確立することや、必要に応じてIT部門が拒否する権限を与えることを通じて具体化できます。IT部門は、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトの実践（本書に概説されているものと、組織によって開発されたものの両方）の重要性を強調する購入基準を開発する権限を与えられるべきです。さらに、IT部門は、購入決定においてこれらの基準を施行する際に、経営幹部によってサポートされるべきです。

特定の技術製品に関連するリスクを受け入れるという組織の決定は、正式に文書化され、上級ビジネス幹部によって承認され、定期的に取締役会に提示されるべきです。

組織のセキュリティ体制をサポートする主要なエンタープライズITサービス（エンタープライズネットワーク、エンタープライズIDおよびアクセス管理、セキュリティ運用および応答機能など）は、組織のミッション成功への重要性に合わせて資金提供される重要なビジネス機能と見なされるべきです。組織は、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトの実践を受け入れる製造者を活用するために、これらの機能をアップグレードする計画を策定すべきです。

可能な場合、組織は主要なITサプライヤーと戦略的関係を築くよう努めるべきです。このような関係には、組織の複数のレベルでの信頼が含まれ、問題を解決し、共有された優先順位を特定するための手段を提供します。セキュリティはそのような関係の重要な要素であるべきであり、組織は関係の公式（契約やベンダー契約など）および非公式の側面の両方において、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトの実践の重要性を強化するよう努めるべきです。

組織は、技術サプライヤーに対し、内部統制の体制と、セキュア・バイ・デザインおよびセキュア・バイ・デフォルトの実践を採用するためのロードマップについての透明性を期待すべきです。

組織内でセキュア・バイ・デフォルトを優先することに加えて、ITリーダーは業界の同業者と協力して、どの製品やサービスがこれらの設計原則を最もよく体現しているかを理解すべきです。これらのリーダーは、製造者が今後のセキュリティイニシアチブに優先順位を付けるのを助けるために、要求を調整すべきです。協力することで、顧客は製造者に有意義な入力を提供し、セキュリティを優先するインセンティブを作成するのに役立ちます。

クラウドシステムを活用する場合、組織は技術サプライヤーとの共有責任モデルを理解していることを確認すべきです。つまり、組織は顧客の責任だけでなく、サプライヤーのセキュリティ責任についても明確にする必要があります。組織は、セキュリティ体制、内部統制、および共有責任モデルの下での義務を果たす能力について透明性のあるクラウドプロバイダーを優先すべきです。

免責事項

本レポートの情報は、情報提供のみを目的として「現状のまま」提供されています。CISAおよび執筆組織は、分析の対象を含むいかなる商用製品またはサービスも推奨しません。サービスマーク、商標、製造者、またはその他による特定の商業体、または商業製品、プロセス、またはサービスへの言及は、CISAおよび執筆組織による推奨、推薦、または支持を構成または暗示するものではありません。この文書はCISAによる共同イニシアチブであり、自動的に規制文書として機能するものではありません。

リソース

CISA

NSA

FBI

NIST

ACSC (Australia)

NCSC-UK

CCCS (Canada)

BSI (Germany)

NCSC-NL (Netherlands)

NISC (Japan)

METI (Japan)

CSA (Singapore)

Other

Discussion

Kyohei FukudaKyohei Fukuda

翻訳ありがとうございました〜　勉強になりました！