CISA他 サイバーセキュリティリスクのバランスを変える：セキュリティ・バイ・デザインとセキュリティ・バイ・デフォルトの原則とアプローチ

こんにちは、丸山満彦です。

CISA、連邦捜査局（FBI）、国家安全保障局（NSA）、オーストラリア、カナダ、英国、ドイツ、オランダ、ニュージーランドのサイバーセキュリティ機関（CERT NZ、NCSC-NZ）は、共同で「サイバーセキュリティリスクのバランスを変える：セキュリティ・バイ・デザインとセキュリティ・バイ・デフォルトのための原則とアプローチ」を策定していますね。。。。この初の共同ガイダンスは、セキュア・バイ・デザインおよびデフォルトの製品を出荷するために必要な緊急措置を取るようメーカーに促していますね。。。

Fice Eyes + ドイツ＋オランダですね...　日本ははいっていませんね...

⚫︎ CISA

・2023.04.13 Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default

・[PDF] 

Shifting the Balance of Cybersecurity Risk:	サイバーセキュリティリスクのバランスを変化させる：
Principles and Approaches for Security-by-Design and -Default	セキュリティ・バイ・デザインとデフォルトの原則とアプローチ
Publication: April 13, 2023	発行： 2023年4月13日
Cybersecurity and Infrastructure Security Agency	サイバーセキュリティおよびインフラストラクチャ・セキュリティ庁
Table of Contents	目次
Table of Contents	目次
Overview: Vulnerable by Design	概要 デザインによる脆弱性
Secure-by-Design	セキュア・バイ・デザイン
Secure-by-Default	セキュア・バイ・デフォルト
Recommendations for Software Manufacturers	ソフトウェアメーカーへの提言
Software Product Security Principles	ソフトウェア製品のセキュリティ原則
Secure-by-Design Tactics	セキュア・バイ・デザインの戦術
Secure-by-Default Tactics	セキュア・バイ・デフォルトの戦術
Hardening vs loosening guides	ハーデニング・ガイドとルーシング・ガイド
Recommendations for Customers	顧客への提言
Disclaimer	免責事項
Resources	リソース
OVERVIEW: VULNERABLE BY DESIGN	概要：デザインによる脆弱性
Technology is integrated into nearly every facet of daily life. Internet-facing systems are connected to critical systems that directly impact our economic prosperity, livelihoods, and even health, ranging from personal identity management to medical care. As only one example, cyber breaches have resulted in hospitals cancelling surgeries and diverting patient care globally. Insecure technology and vulnerabilities in critical systems may invite malicious cyber intrusions, leading to serious potential safety[1] risks.	技術は、日常生活のほぼすべての場面に組み込まれている。インターネットに接続されたシステムは、私たちの経済的繁栄や生活、さらには個人のID管理から医療に至るまで、健康に直接影響を与える重要なシステムに接続されている。ほんの一例であるが、サイバー侵害によって、病院が手術をキャンセルしたり、患者の治療を迂回させたりする事態が世界的に発生している。重要なシステムにおける安全でない技術や脆弱性は、悪意のあるサイバー侵入を招き、潜在的な安全性[1]の重大なリスクにつながる可能性がある。
Now more than ever, it is crucial for technology manufacturers to make Secure-by-Design and Secure-by-Default the focal points of product design and development processes. Some vendors have made great strides driving the industry forward in software assurance, while others lag behind. The authoring agencies strongly encourage every technology manufacturer to build their products in a way that prevents customers from having to constantly perform monitoring, routine updates, and damage control on their systems to mitigate cyber intrusions. Manufacturers are encouraged to take ownership of improving the security outcomes of their customers. Historically, technology manufacturers have relied on fixing vulnerabilities found after the customers have deployed the products, requiring the customers to apply those patches at their own expense. Only by incorporating Secure-by-Design practices will we break the vicious cycle of creating and applying fixes.	技術メーカーにとって、セキュア・バイ・デザインとセキュア・バイ・デフォルトを製品の設計・開発プロセスの中心に据えることは、これまで以上に重要な課題となっている。ソフトウェア保証の分野で業界を大きく前進させたベンダーもあれば、遅れをとったベンダーもある。機関または省庁は、すべての技術メーカーが、顧客がサイバー侵入を軽減するためにシステムの監視、定期的な更新、ダメージコ ントロールを常に行う必要がないような方法で製品を構築することを強く推奨する。製造業者は、顧客のセキュリティの成果を向上させるためのオーナーシップを持つことが奨励される。歴史的に、技術メーカーは、顧客が製品を導入した後に発見された脆弱性の修正に頼っており、顧客が自費でパッチを適用することを要求してきました。セキュア・バイ・デザインの手法を取り入れることで、修正パッチの作成と適用という悪循環を断ち切ることができる。
To accomplish this high standard of software security, the authoring agencies encourage manufacturers to prioritize the integration of product security as a critical prerequisite to features and speed to market. Over time, engineering teams will be able to establish a new steady-state rhythm where security is truly designed-in and takes less effort to maintain. Reflecting this perspective, the European Union reinforces the importance of product security in the Cyber Resilience Act, emphasizing that manufacturers should implement security throughout a product‘s life-cycle in order to prevent manufacturers from introducing vulnerable products into the market.	この高水準のソフトウェア・セキュリティを実現するために、機関 または省庁はメーカーに対し、製品セキュリティの統合を、機能と市場投入のスピードの重要な前提条件と して優先することを奨励している。時が経てば、エンジニアリングチームは、セキュリティが真にデザインインされ、維持にかかる労力が少なくなるような、新しい定常状態のリズムを確立できるようになるであろう。このような視点を反映して、欧州連合はサイバーレジリエンス法の中で製品セキュリティの重要性を強化し、メーカーが脆弱な製品を市場に投入することを防ぐために、製品のライフサイクルを通じてセキュリティを実装することを強調している。
To create a future where technology and associated products are safer for customers, the authoring agencies urge manufacturers to revamp their design and development programs to permit only Secure-by-Design and -Default products to be shipped to customers. Products that are Secure-by-Design are those where the security of the customers is a core business goal, not just a technical feature. Secure-by-Design products start with that goal before development starts. Secure-by-Default products are those that are secure to use “out of the box” with little to no configuration changes necessary and security features available without additional cost. Together, these two principles move much of the burden of staying secure to manufacturers and reduce the chances that customers will fall victim to security incidents resulting from misconfigurations, insufficiently fast patching, or many other common issues.	技術や関連製品が顧客にとってより安全である未来を実現するため、機関または省庁は、設計・開発プログラムを見直し、セキュア・バイ・デザインおよびデフォルトの製品のみを顧客に出荷できるようにすることをメーカーに求めている。セキュア・バイ・デザイン製品とは、顧客のセキュリティが単なる技術的特徴ではなく、ビジネスの中核的な目標である製品のことである。セキュア・バイ・デザインの製品は、開発開始前にその目標に着手する。セキュア・バイ・デフォルト製品とは、「箱から出してすぐに」安全に使用できる製品であり、設定の変更はほとんど必要なく、追加コストなしでセキュリティ機能を利用できるものである。この2つの原則を併用することで、安全性を維持するための負担の多くをメーカーに移し、設定ミスや不十分なパッチ適用、その他多くの一般的な問題に起因するセキュリティインシデントに顧客が陥る可能性を低減することができる。
The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI) and the following international partners[2] provide the recommendations in this guide as a roadmap for technology manufacturers to ensure security of their products:	サイバーセキュリティおよびインフラストラクチャ・セキュリティ局（CISA）、国家安全保障局（NSA）、連邦捜査局（FBI）および以下の国際的なパートナー [2]は、技術メーカーが製品のセキュリティを確保するためのロードマップとして、本ガイドの推奨事項を提供する：
•       Australian Cyber Security Centre (ACSC)	・オーストラリア・サイバーセキュリティセンター(ACSC)
•       Canadian Centre for Cyber Security (CCCS)	・カナディアン・センター・フォー・サイバー・セキュリティ(CCCS)
•       United Kingdom’s National Cyber Security Centre (NCSC-UK)	・英国国立サイバーセキュリティセンター(NCSC-UK)
•       Germany’s Federal Office for Information Security (BSI)	・ドイツ連邦情報セキュリティ局(BSI)
•       Netherlands’ National Cyber Security Centre (NCSC-NL)	・オランダ国立サイバーセキュリティセンター(NCSC-NL)
•       Computer Emergency Response Team New Zealand (CERT NZ) and New Zealand’s National Cyber Security Centre (NCSC-NZ).	・コンピュータ緊急対応チームニュージーランド（CERT NZ）およびニュージーランド国立サイバーセキュリティセンター（NCSC-NZ）。
The authoring agencies recognize the contributions by many private sector partners in advancing security-by-design and security-by-default. This product is intended to progress an international conversation about key priorities, investments, and decisions necessary to achieve a future where technology is safe, secure, and resilient by design and default. Toward that end, the authoring agencies seek feedback on this product from interested parties and intend to convene a series of listening sessions to further refine, specify, and advance our guidance to achieve our shared goals.	機関または省庁は、セキュリティ・バイ・デザインおよびセキュリティ・バイ・デフォルトの推進における多くの民間セクターのパートナーの貢献を認識している。本製品は、設計上およびデフォルトで技術が安全、セキュア、レジリエントである未来を実現するために必要な主要優先事項、投資、意思決定に関する国際的な対話を進めることを目的としている。この目的を達成するため、機関または省庁は、関係者からの本製品に関するフィードバックを求め、また、共通の目標を達成するため、ガイダンスをさらに洗練し、特定し、前進させるために、一連のリスニングセッションを開催する予定である。
For more information on the importance of product safety, see CISA’s article, The Cost of Unsafe Technology and What We Can Do About It.	製品安全の重要性については、CISAの記事「The Cost of Unsafe Technology and What We Can Do About It」を参照のこと。
Secure-by-Design	セキュア・バイ・デザイン
“Secure-by-Design” means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure. Software manufacturers should perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape.	「セキュア・バイ・デザイン」とは、悪意のあるサイバーアクターがデバイス、データ、接続されたインフラへのアクセスを成功させることから合理的に保護する方法で技術製品が構築されていることを意味する。ソフトウェアメーカーは、重要なシステムに対する一般的なサイバー脅威を特定・列挙するリスク評価を行い、進化するサイバー脅威の状況を考慮した保護策を製品の設計図に含める必要がある。
Secure information technology (IT) development practices and multiple layers of defense— known as defense-in-depth—are also recommended to prevent adversary activity from compromising systems or obtaining unauthorized access to sensitive data. The authoring agencies recommend manufacturers use a tailored threat model during the product development stage to address all potential threats to a system and account for each system’s deployment process.	また、敵によるシステムの侵害や機密データへの不正アクセスを防ぐため、安全な情報技術（IT）開発の実践と多重防御（Defense-in-Depthとして知られている）も推奨されている。機関または省庁は、メーカーが製品開発段階で、システムに対する潜在的なすべての脅威に対応し、各システムの展開プロセ スを考慮したカスタマイズされた脅威モデルを使用することを推奨する。
The authoring agencies urge manufacturers to take a holistic security approach for their products and platforms. Secure-by-Design development requires the investment of significant resources by software manufacturers at each layer of the product design and development process that cannot be “bolted on” later. It requires strong leadership by the manufacturer’s top business executives to make security a business priority, not just a technical feature. This collaboration between business leaders and technical teams extends from the early stages of design and development, through customer deployment and maintenance. Manufacturers are encouraged make hard tradeoffs and investments, including those that will be “invisible” to the customers, such as migrating to programming languages that eliminate widespread vulnerabilities. They should prioritize features, mechanisms, and implementation of tools that protect customers rather than product features that seem appealing but enlarge the attack surface.	機関または省庁は、メーカーが自社の製品やプラットフォームに対して全体的なセキュリティアプローチを取ることを強く求める。セキュア・バイ・デザインの開発には、製品の設計・開発プロセスの各層で、ソフトウェアメーカーが後から「ボルトオン」することのできない重要なリソースを投資することが必要である。また、セキュリティが単なる技術的な特徴ではなく、ビジネス上の優先事項であることを示すために、メーカーのトップビジネスエグゼクティブによる強いリーダーシップが必要である。ビジネスリーダーと技術チームのコラボレーションは、設計・開発の初期段階から、顧客への配備やメンテナンスに至るまで続く。製造業者は、広範な脆弱性を排除するプログラミング言語への移行など、顧客には「見えない」ものも含めて、厳しいトレードオフと投資を行うことが奨励される。また、魅力的に見えるが攻撃対象が広がるような製品機能ではなく、顧客を守るための機能、メカニズム、ツールの実装を優先する必要がある。
There is no single solution to end the persistent threat of malicious cyber actors exploiting technology vulnerabilities, and products that are “Secure-by-Design” will continue to suffer vulnerabilities; however, a large set of vulnerabilities are due to a relatively small subset of root causes. Manufacturers should develop written roadmaps to align their existing product portfolios with more Secure-by-Design practices, ensuring to only deviate in exceptional situations.	技術の脆弱性を悪意あるサイバーアクターが悪用するという永続的な脅威を終わらせる唯一の解決策はなく、「セキュア・バイ・デザイン」である製品も脆弱性を抱え続けることになる。製造業者は、既存の製品ポートフォリオをよりセキュア・バイ・デザインの実践に合わせるためのロードマップを文書で作成し、例外的な状況においてのみ逸脱することを保証する必要がある。
The authoring agencies acknowledge that taking ownership of the security outcomes for customers and ensuring this level of customer security may increase development costs. However, investing in “Secure-by-Design" practices while developing new technology products and maintaining existing ones can substantially improve the security posture of customers and reduce the likelihood of being compromised. Secure-by-Design principles not only strengthen the security posture for customers and brand reputation for developers but also lowers maintenance and patching costs for manufacturers in the long term.	機関または省庁は、顧客に対するセキュリティ成果のオーナーシップを持ち、このレベルの顧客セキュリティを確保することが、開発コストを増加させる可能性があることを認めている。しかし、新しい技術製品の開発や既存の製品の保守を行う際に「セキュア・バイ・デザイン」の実践に投資することで、顧客のセキュリティ態勢を大幅に改善し、危険にさらされる可能性を低減することができる。セキュア・バイ・デザインの原則は、顧客のセキュリティ態勢や開発者のブランド評価を強化するだけでなく、メーカーにとっても長期的にメンテナンスとパッチ適用のコストを低減することができる。
The Recommendations for Software Manufacturers section listed below provides a list of recommended product development practices and policies for manufacturers to consider.	以下の「ソフトウェアメーカーへの提言」では、メーカーが考慮すべき推奨される製品開発の実践と方針の一覧を掲載している。
Secure-by-Default	セキュア・バイ・デォルト
“Secure-by-Default” means products are resilient against prevalent exploitation techniques out of the box without additional charge. These products protect against the most prevalent threats and vulnerabilities without end-users having to take additional steps to secure them. Secure-by-Default products are designed to make customers acutely aware that when they deviate from safe defaults, they are increasing the likelihood of compromise unless they implement additional compensating controls.	「セキュア・バイ・デォルト 」 とは、一般的な悪用攻撃に対して、追加費用なしにすぐに使用できる製品を意味する。これらの製品は、エンドユーザーがセキュリティを確保するために追加の手順を踏むことなく、最も一般的な脅威や脆弱性から保護する。セキュア・バイ・デォルト 製品は、安全なデフォルト設定から外れた場合、追加の補償コントロールを実装しない限り、侵害の可能性が高まることを顧客に強く認識させるように設計されている。
•       A secure configuration should be the default baseline. Secure-by-Default products automatically enable the most important security controls needed to protect enterprises from malicious cyber actors, as well as provide the ability to use and further configure security controls at no additional cost.	・安全な構成はデフォルトのベースラインであるべきである。セキュア・バイ・デォルト製品は、悪意のあるサイバー行為者から企業を保護するために必要な最も重要なセキュリティ制御を自動的に有効にし、さらに追加費用なしでセキュリティ制御を使用し、さらに構成する能力を提供する。
•       The complexity of security configuration should not be a customer problem. Organizational IT staff are frequently overloaded with security and operational responsibilities, thus resulting in limited time to understand and implement the security implications and mitigations required for a robust cybersecurity posture. Through optimizing secure product configuration—securing the “default path”— manufacturers can aid their customers by ensuring their products are manufactured, distributed, and used securely in accordance with “Secure-by-Default” standards.	・セキュリティ設定の複雑さは、お客様の問題であってはならない。組織のITスタッフは、セキュリティと運用の責任に追われることが多く、その結果、強固なサイバーセキュリティ態勢に必要なセキュリティの意味と緩和策を理解し、実装する時間が限られている。メーカーは、セキュアな製品構成を最適化し、「デフォルトパス」を確保することで、「セキュア・バイ・デフォルト」基準に従って製品が安全に製造、配布、使用されることを保証し、顧客を支援することができる。
Manufacturers of products that are “Secure-by-Default” do not charge extra for implementing additional security configurations. Instead, they include them in the base product like seatbelts are included in all new cars. Security is not a luxury option but is closer to the standard every customer should expect without negotiating or paying more.	「セキュア・バイ・デォルト 」製品のメーカーは、追加のセキュリティ設定を実装するために追加費用を請求することはない。その代わり、すべての新車にシートベルトが装備されているように、基本製品に含まれている。セキュリティは贅沢なオプションではなく、交渉や追加費用を支払うことなく、すべての顧客が期待すべき標準に近いものである。
RECOMMENDATIONS FOR SOFTWARE MANUFACTURERS	ソフトウェアメーカーへの提言
This joint guide provides recommendations to manufacturers for developing a written roadmap to implement and ensure IT security. The authoring agencies recommend software manufacturers implement the strategies outlined in the sections below to take ownership of the security outcomes of their customers through Secure-by-Design and -Default principles.	この共同ガイドは、IT セキュリティを実装し確保するためのロードマップを文書化し、製造業者に推奨するものである。著者である機関 省は、ソフトウェア製造者が、セキュア・バイ・デザインおよびデフォルトの原則を通じて、顧客のセキュリ ティ成果のオーナーシップを持つために、以下のセクションで説明する戦略を実施することを推奨する。
Software Product Security Principles	ソフトウェア製品のセキュリティ原則
Technology manufacturers are encouraged to adopt a strategic focus that prioritizes software security. The authoring agencies developed the below three core principles to guide software manufacturers in building software security into their design processes prior to developing, configuring, and shipping their products.	技術メーカーは、ソフトウェアセキュリティを優先する戦略的焦点を採用することが推奨される。機関または省庁は、ソフトウェアメーカーが製品の開発、構成、出荷に先立ち、ソフトウェアセキュリティを設計プロセ スに組み込む際の指針として、以下の3つの基本原則を策定しました。
1.    The burden of security should not fall solely on the customer. Software manufacturers should take ownership of the security outcomes of their customer’s purchase and evolve their products accordingly.	1.    セキュリティの負担を顧客だけに負わせるべきではない。ソフトウェアメーカーは、顧客が購入した製品のセキュリティの結果について責任を持ち、それに応じて製品を進化させるべきである。
2.    Embrace radical transparency and accountability. Software manufacturers should pride themselves in delivering safe and secure products, as well as differentiating themselves among the rest of the manufacturer community based on their ability to do so. This may include sharing information they learn from their customer deployments, such as the uptake of strong authentication mechanisms by default. It also includes a strong commitment to ensure vulnerability advisories and associated common vulnerability and exposure (CVE) records are complete and accurate. However,  of the temptation to count CVEs as a negative metric, since such numbers are also a sign of a healthy code analysis and testing community.	2.    透明性と説明責任を受け入れる。ソフトウェアメーカーは、安全でセキュアな製品を提供することに誇りを持ち、その能力によって他のメーカーコミュニティと差別化する必要がある。これには、強力な認証メカニズムをデフォルトで採用しているなど、顧客の導入から学んだ情報を共有することも含まれる。また、脆弱性アドバイザリや関連する共通脆弱性・暴露（CVE）記録が完全かつ正確であることを保証するための強いコミットメントも含まれる。しかし、CVEをネガティブな指標としてカウントする誘惑に負けないこと。このような数値は、健全なコード分析およびテストコミュニティの証でもある。
3. Build organizational structure and leadership to achieve these goals. While technical subject matter expertise is critical to product security, senior executives are the primary decision makers for implementing change in an organization. Executive-level commitment for software manufacturers to prioritize security as a critical element of product development requires the development of partnerships with an organization’s customers to understand:	3. これらの目標を達成するための組織体制とリーダーシップを構築する。製品セキュリティには技術的な専門知識が不可欠であるが、組織の変革を実施するための主要な意思決定者は上級管理職である。ソフトウェアメーカーが製品開発の重要な要素としてセキュリティを優先することを幹部レベルで約束するには、組織の顧客とパートナーシップを築き、理解を深めることが必要である：
a.     The product deployment scenario guidance along with tailored threat model	a.     製品導入シナリオのガイダンスと、カスタマイズされた脅威モデル
b.     Proposed implementation for security controls to align to Secure-by-Default principles	b.     セキュア・バイ・デフォルトの原則に沿ったセキュリティ制御の実装案
c.     Resource allocation strategies tailored to company size and the ability to replace legacy development practices with Secure-by-Design practices	c.     企業規模に合わせた資源配分戦略、レガシーな開発手法をセキュア・バイ・デザインに置き換える能力
d.     The need to maintain an open line of communication for feedback internallyand externally (e.g., employee and customer feedback) regarding product security issues. Software security should be emphasized in internal forums (e.g., all-hands or brown bags), as well as external product marketing and customer engagement	d.     製品のセキュリティ問題に関する社内外のフィードバック（従業員や顧客からのフィードバックなど）のために、オープンなコミュニケーションラインを維持する必要がある。ソフトウェアセキュリティは、社内フォーラム（例：オールハンドやブラウンバッグ）、社外の製品マーケティングや顧客エンゲージメントで強調する必要がある。
e.     Measurements of effectiveness within customer deployments. Senior executiveleaders will want to know where investments in security by design and default are helping customers by slowing the pace of security patches, reducing configuration errors, and minimizing attack surface.	e.     顧客の配備における有効性の測定。シニアエグゼクティブリーダーは、セキュリティパッチの適用ペースを遅らせたり、設定エラーを減らしたり、攻撃対象領域を最小化したりすることで、セキュリティバイデザインとデフォルトへの投資が顧客の役に立っていることを知りたいと思うだろう。
To enable these three principles, manufacturers should consider several operational tactics to evolve their development processes.	これらの3つの原則を実現するために、メーカーは、開発プロセスを進化させるためのいくつかの運用戦術を検討する必要がある。
Convene routine meetings with company executive leadership to drive the importance of Secure-by-Design and Secure-by-Default within the organization. Policies and procedures should be established to reward production teams that develop products adhering to these principles, which could include awards for implementing outstanding software security practices or incentives for job ladders and promotion criteria.	セキュア・バイ・デザインとセキュア・バイ・デフォルトの重要性を組織内に浸透させるため、会社の経営幹部と定期的にミーティングを行う。これらの原則に準拠した製品を開発した製造チームに報いるための方針と手順を確立する。この方針と手順には、優れたソフトウェアセキュリティの実践に対する表彰や、職階や昇進基準に対するインセンティブを含めることができる。
Operate around the importance of software security to business success. For example, consider assigning a “software security leader” or a “software security team” that upholds business and IT practices to directly link software security standards and manufacturer accountability. Manufacturers should ensure they have robust, independent product security assessment and evaluation programs for their products.	事業の成功に対するソフトウエアセキュリティの重要性を中心に運営する。例えば、「ソフトウエアセキュリティリーダー」や、ビジネスと IT の実践を支持する「ソフトウエアセキュリティチーム」を配置し、ソフトウ エアセキュリティ基準とメーカーの説明責任を直接関連付けることを検討する。製造業者は、自社製品について、強固で独立した製品セキュリティ評価及び評価プログラムを確実に実施する。
Use a tailored threat model during development to prioritize the most critical and high-impact	開発時にカスタマイズされた脅威モデルを使用し、最も重要で影響度の高いものを優先する。
products. Threat models consider a product’s specific use-case and enables development teams to fortify products. Finally, senior leadership should hold teams accountable for delivering secure products as a key element of product excellence and quality.	製品を強化することができる。脅威モデルは、製品の特定のユースケースを考慮し、開発チームが製品を強化することを可能にする。最後に、シニアリーダーは、製品の卓越性と品質の重要な要素として、安全な製品を提供する責任をチームに負わせる必要がある。
Secure-by-Design Tactics	セキュア・バイ・デザインの戦術
The Secure Software Development Framework (SSDF), also known as National Institute of Standards and Technology’s (NIST) SP 800-218, is a core set of high-level secure software development practices that can be integrated into each stage of the software development lifecycle (SDLC). Following these practices can help software producers become more effective at finding and removing vulnerabilities in released software, mitigate the potential impact of the exploitation of vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences.	Secure Software Development Framework (SSDF) は、国立標準技術研究所 (NIST) の SP 800-218 としても知られており、ソフトウェア開発ライフサイクル (SDLC) の各段階に統合できる、高レベルの安全なソフトウェア開発プラクティスのコアセットである。これらのプラクティスに従うことで、ソフトウェアメーカーは、リリースされたソフトウェアの脆弱性の発見と除去をより効果的に行い、脆弱性の悪用による潜在的な影響を軽減し、脆弱性の根本原因に対処して将来の再発を防止することができる。
The authoring agencies encourage the use of Secure-by-Design tactics, including principles that reference SSDF practices. Software manufacturers should develop a written roadmap to adopt more Secure-by-Design software development practices across their portfolio. The following is a non-exhaustive list of illustrative roadmap best practices:	作成機関は、SSDFの実践を参照する原則を含め、セキュア・バイ・デザインの戦術を使用することを推奨する。ソフトウェアメーカーは、ポートフォリオ全体でより多くのセキュア・バイ・デザインのソフトウェア開発手法を採用するために、書面によるロードマップを作成する必要がある。以下は、ロードマップのベストプラクティスを例示する非網羅的なリストである：
•       Memory safe programming languages (SSDF PW.6.1): Prioritize the use of memory safe languages wherever possible. The authoring agencies acknowledge that other memory specific mitigations, such as address space layout randomization (ASLR), control-flow integrity (CFI), and fuzzing are helpful for legacy codebases, but insufficient to be viewed as secure-by-design as they do not adequately prevent exploitation. Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift. Read NSA’s memory safety information sheet for more.	・メモリ安全プログラミング言語(SSDF PW.6.1): メモリ安全プログラミング言語(SSDF PW.6.1):可能な限り,メモリ安全言語の使用を優先する。メモリ安全プログラミング言語(SSDF PW.6.1):可能な限りメモリ安全言語の使用を優先すること。アドレス空間レイアウト無作為化(ASLR),制御フロー完全性(CFI),ファジングなどのメモリ特有の緩和策は,レガシーコードベースには有用だが,悪用を十分に防止できないため,セキュア・バイ・デザインとして見るには不十分であることを,作成機関は認めている。最新のメモリ安全言語の例としては,C#,Rust,Ruby,Java,Go,Swiftなどがある。詳しくは,NSAのメモリ安全性情報シートを参照のこと。
•       Secure Hardware Foundation: Incorporate architectural features that enable finegrained memory protection, such as those described by Capability Hardware Enhanced RISC Instructions (CHERI) that can extend conventional hardware Instruction-Set Architectures (ISAs). For more information visit, University of Cambridge’s CHERI webpage.	・セキュアなハードウェア基盤： 従来のハードウェア命令セットアーキテクチャ（ISA）を拡張できるCapability Hardware Enhanced RISC Instructions（CHERI）に代表される、きめ細かいメモリ保護を可能にするアーキテクチャ機能を搭載する。詳しくは、ケンブリッジ大学のCHERIウェブページを参照のこと。
•       Secure Software Components (SSDF PW 4.1): Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks,) from verified commercial, open source, and other third-party developers to ensure robust security in consumer software products.	- 安全なソフトウェア部品 (SSDF PW 4.1)： 消費者向けソフトウェア製品の強固なセキュリティを確保するため、安全性の高いソフトウェアコンポーネント（ソフトウェアライブラリ、モジュール、ミドルウェア、フレームワークなど）を、検証済みの商用、オープンソース、その他のサードパーティ開発者から取得し、維持する。
•       Web template frameworks (SSDF PW.5.1): Use web template frameworks that implement automatic escaping of user input to avoid web attacks such as cross-site scripting.	・ウェブテンプレートフレームワーク(SSDF PW.5.1): クロスサイトスクリプティングなどのWeb攻撃を回避するために,ユーザー入力の自動エスケープを実装したWebテンプレートフレームワークを使用する。
•       Parameterized queries (SSDF PW 5.1): Use parameterized queries rather than including user input in queries, to avoid SQL injection attacks.	・パラメータ化されたクエリ（SSDF PW 5.1） SQLインジェクション攻撃を回避するため、クエリにユーザー入力を含めず、パラメータ化されたクエリを使用する。
•       Static and dynamic application security testing (SAST/DAST) (SSDF PW.7.2, PW.8.2):	- 静的および動的アプリケーションセキュリティテスト（SAST/DAST）（SSDF PW.7.2、 PW.8.2）：
Use these tools to analyze product source code and application behavior to detect error-prone practices. These tools cover issues ranging from improper management of memory to error prone database query construction (e.g., unescaped user input leading to SQL injection). SAST and DAST tools can be incorporated into development processes and run automatically as part of software development. SAST and DAST should complement other types of testing, such as unit testing and integration testing, to ensure products comply with expected security requirements. When issues are identified, manufacturers should perform root-cause analysis to systemically address vulnerabilities.	これらのツールを使用して、製品のソースコードやアプリケーションの動作を分析し、エラーとなりやすい行為を検出する。これらのツールは、メモリの不適切な管理から、エラーを起こしやすいデータベースクエリの構築（例えば、SQLインジェクションにつながるエスケープされていないユーザー入力）までの問題をカバーしている。SAST および DAST ツールは、開発プロセスに組み込むことができ、ソフトウェア開発の一部として自動的に実行されます。SAST と DAST は、製品が期待されるセキュリティ要件に適合していることを確認するために、単体テストや統合テ ストなど、他の種類のテストを補完する必要がある。問題が特定された場合、製造者は根本原因分析を実施し、脆弱性に体系的に対処する必要がある。
•       Code review (SSDF PW.7.1, PW.7.2): Strive to ensure that code submitted into products goes through peer review by other developers to ensure higher quality.	・コードレビュー(SSDF PW.7.1, PW.7.2): 製品に含まれるコードが,他の開発者によるピアレビューを受け,より高い品質を確保するよう努める。
•       Software Bill of Materials (SBOM) (SSDF PS.3.2, PW.4.1): Incorporate the creation of SBOM[3] to provide visibility into the set of software that goes into products.	・ソフトウェア部品表（SBOM）（SSDF PS.3.2、 PW.4.1）： SBOM[3]の作成を取り入れ、製品に搭載される一連のソフトウェアの可視性を提供する。
•       Vulnerability disclosure programs (SSDF RV.1.3): Establish vulnerability disclosure programs that allow security researchers to report vulnerabilities and receive legal safe harbor in doing so. As part of this, suppliers should establish processes to determine root causes of discovered vulnerabilities. Such processes should include determining whether adopting any of the Secure-by-Design practices in this document (or other similar practices) would have prevented the introduction of the vulnerability.	・脆弱性開示プログラム（SSDF RV.1.3）： セキュリティ研究者が脆弱性を報告し、その際に法的なセーフハーバーを受けられるような脆弱性開示プログラムを確立する。この一環として、サプライヤーは、発見された脆弱性の根本原因を特定するプロセスを確立する必要がある。このようなプロセスには、本文書におけるセキュア・バイ・デザインの実践（または他の類似の実践）のいずれかを採用すれば、脆弱性の導入を防ぐことができたかどうかを判断することが含まれるべきである。
•       CVE completeness: Ensure that published CVEs include root cause or common weakness enumeration (CWE) to enable industry-wide analysis of software security root causes. While ensuring that every CVE is correct and complete can take extra time, it allows disparate entities to spot industry trends that benefit all manufacturers and customers. For more information on managing vulnerabilities, see CISA’s Stakeholderspecific SVCC guidance.	・CVE の完全性： ソフトウェアセキュリティの根本原因を業界全体で分析できるように、公開されたCVEに根本原因または共通弱点列挙（CWE）が含まれていることを確認する。すべてのCVEが正しく、完全であることを確認するためには、余分な時間がかかることもあるが、異質な団体が業界の動向を把握することができ、すべてのメーカーと顧客に利益をもたらする。脆弱性管理の詳細については、CISAのステークホルダー別SVCCガイダンスをご覧ください。
•       Defense-in-Depth: Design infrastructure so that the compromise of a single security control does not result in compromise of the entire system. For example, ensuring that user privileges are narrowly provisioned and access control lists are employed can reduce the impact of a compromised account. Also, software sandboxing techniques can quarantine a vulnerability to limit compromise of an entire application.	・徹底的な防御: 単一のセキュリティ制御が侵害されても,システム全体が侵害されないようにインフラを設計する。例えば,ユーザー特権を限定的にプロビジョニングし,アクセス制御リストを採用することで,侵害されたアカウントの影響を軽減することができる。また,ソフトウェアのサンドボックス化技術により,脆弱性を隔離し,アプリケーション全体の侵害を抑制することができる。
•       Satisfy Cyber Performance Goals (CPGs): Design products that meet basic security practices. CISA’s Cybersecurity Performance Goals outline fundamental, baseline cybersecurity measures organizations should implement. Additionally, for more ways to strengthen your organization’s posture, see the UK’s Cyber Assessment Framework which shares similarities to CISA’s CPGs. If a manufacturer fails to meet the CPGs— such as not requiring phishing-resistant multi-factor authentication for all employees— then they cannot be seen as delivering Secure-by-Design products.	・サイバーパフォーマンスゴール（CPG）を満足させる： 基本的なセキュリティ対策に適合した製品を設計する。CISAのCybersecurity Performance Goalsは、組織が実施すべき基本的なサイバーセキュリティ対策について概説している。さらに、組織の態勢を強化する方法として、CISAのCPGと共通する英国のCyber Assessment Frameworkを参照してください。メーカーがCPGを満たしていない場合（例えば、フィッシングに強い多要素認証を全社員に要求していない場合）、セキュリティ・バイ・デザイン製品を提供しているとは見なされません。
The authoring agencies recognize that these changes are significant shifts in an organization’s posture. As such, their introduction should be prioritized based on criticality, complexity, and business impact. These practices can be introduced for new software and incrementally expanded to cover additional use cases and products. In some cases, the criticality and risk posture of a certain product may merit an accelerated schedule to adopt these practices. In others, practices can be introduced into a legacy codebase and remediated over time.	機関または省庁は、これらの変更が組織の態勢を大きく変化させるものであることを認識している。そのため、その導入は、重要性、複雑性、およびビジネスへの影響に基づいて優先的に行われる必要がある。これらのプラクティスは、新しいソフトウェアに導入し、追加のユースケースや製品に適用するために段階的に拡大することができる。場合によっては、ある製品の重要性とリスクポストを考慮し、これらのプラクティスを導入するスケジュールを早めることができる。また、レガシーコードベースにプラクティスを導入し、時間をかけて改善することも可能である。
Secure-by-Default Tactics	セキュア・バイ・デフォルトの戦術
In addition to adopting Secure-by-Design development practices, the authoring agencies recommend software manufacturers prioritize Secure-by-Default configurations in their products. These should strive to update products to conform to these practices as they are refreshed. For example:	機関または省庁は、セキュア・バイ・デザインの開発手法を採用することに加え、ソフトウェアメーカーが自社製品において セキュア・バイ・デフォルト構成を優先することを推奨する。また、ソフトウェアメーカーは、製品が更新されるたびに、これらのプラクティスに適合するように更新するよう努めるべきである。例えば、以下のようなことである：
•       Eliminate default passwords: Products should not come with default passwords that are universally shared. To eliminate default passwords, the authoring agencies recommend products require administrators to set a strong password during installation and configuration.	・デフォルトのパスワードをなくす: 製品に,一般的に共有されるデフォルトのパスワードが付属しているべきではない。デフォルトのパスワードをなくすために,機関または省庁は,製品のインストールと設定の際に,管理者が強力なパスワードを設定することを義務付けることを推奨する。
o Mandate Multifactor Authentication (MFA) for privileged users. We observe that many enterprise deployments are managed by administrators who have not protected their accounts with MFA. Given that administrators are high value targets, products should make MFA opt-out rather than opt-in. Further, the system should regularly prompt the administrator to enroll in MFA until they have successfully enabled it on their account.  Netherlands’ NCSC has guidance that parallels CISA’s, visit their Mature Authentication Factsheet for more information.	o 特権ユーザーに対する多要素認証（MFA）の義務付け。私たちは、多くの企業で、MFA でアカウントを保護していない管理者によって管理されていることを確認している。管理者は高価なターゲットであるため、製品は MFA をオプトインではなく、オプトアウトにする必要がある。さらに、管理者が自分のアカウントで MFA を有効にするまで、システムは定期的に MFA への登録を促す必要がある。 オランダのNCSCは、CISAのガイダンスと類似したガイダンスを提供している。詳細については、Mature Authentication Factsheetを参照のこと。
•       Single sign-on (SSO): IT applications should implement single sign on technology via modern open standards. Examples include Security Assertion Markup Language (SAML) or OpenID Connect (OIDC.) This capability should be made available by default at no additional cost.	・シングルサインオン(SSO): ITアプリケーションは,最新のオープンスタンダードを通じてシングルサインオン技術を実装する必要がある。この機能は,デフォルトで追加コストなしに利用できるようにする必要がある。
•       Secure Logging: Provide high-quality audit logs to customers at no extra charge. Audit logs are crucial for detecting and escalating potential security incidents. They are also crucial during an investigation of a suspected or confirmed security incident. Consider best practices such as providing easy integration with security information and event management (SIEM) systems with application programming interface (API) access that uses coordinated universal time (UTC), standard time zone formatting, and robust documentation techniques.	・安全なロギング： 高品質の監査ログを追加費用なしで顧客に提供する。監査ログは、潜在的なセキュリティインシデントを検出し、エスカレートさせるために重要である。また、セキュリティインシデントが疑われる、あるいは確認された場合の調査においても、監査ログは極めて重要である。セキュリティ情報およびイベント管理（SIEM）システムとの統合を容易にするため、協定世界時（UTC）を使用したアプリケーションプログラミングインターフェース（API）アクセス、標準タイムゾーンフォーマット、堅牢な文書化技術などのベストプラクティスを考慮する。
•       Software Authorization Profile: Software suppliers should provide recommendations on authorized profile roles and their designated use case. Manufacturers should include a visible warning that notifies customers of an increased risk if they deviate from the recommended profile authorization. For example: Medical doctors can view all patient records, but a medical scheduler has limited access to address information required for scheduling appointments.	・ソフトウェアの認証プロファイル: ソフトウェア供給者は,認可されたプロファイルの役割とその指定されたユースケースに関する推奨事項を提供すべきである。製造者は,推奨されるプロファイルの承認から外れた場合,リスクが増大することを顧客に通知する目に見える警告を含めるべきである。例えば,以下のような場合である: 医師はすべての患者記録を閲覧できるが,医療スケジューラーは予約に必要な住所情報へのアクセスは制限されている。
•       Forward-looking security over backwards compatibility: Too often, backwardscompatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even if it means causing breaking changes.	・後方互換性よりも将来を見据えたセキュリティ: 後方互換性のあるレガシー機能が,製品のセキュリティにリスクをもたらすにもかかわらず,製品に含まれ,しばしば有効化されることがある。後方互換性よりもセキュリティを優先し,セキュリティチームには,たとえ変更を余儀なくされても,安全でない機能を削除する権限を与える。
•       Track and reduce “hardening guide” size: Reduce the size of “hardening guides” produced for products and strive to ensure that the size shrinks over time as new versions of the software are released. Integrate components of the “hardening guide” as the default configuration of the product. The authoring agencies recognize that shortened hardening guides result from ongoing partnership with existing customers and include efforts by many product teams, including user experience (UX).	・「ハーデニング・ガイド」のサイズを追跡し、縮小する： 製品のために作成される「ハーデニング・ガイド」のサイズを縮小し、ソフトウェアの新バージョンがリリースされるにつれてサイズが縮小されるように努力する。「ハーデニング・ガイド」の構成要素を、製品のデフォルト構成として統合する。短縮されたハーデニング・ガイドは、既存顧客との継続的なパートナーシップから生まれ、ユーザエクスペリエンス（UX）を含む多くの製品チームによる努力を含んでいることを、作成機関は認識する。
•       Consider the user experience consequences of security settings: Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats.	・セキュリティ設定がもたらすユーザーエクスペリエンスを考慮する: 新しい設定が増えるたびに,エンドユーザの認知的負担が増えるので,それがもたらすビジネス上の利益と合わせて評価する必要がある。その代わりに,最も安全な設定がデフォルトで製品に統合されていることが理想的である。設定が必要な場合,デフォルトのオプションは,一般的な脅威に対して広く安全であるべきである。
The authoring agencies acknowledge these changes may have operational effects on how the software is employed. Thus, customer input is critical in balancing operational and security considerations. The authoring agencies believe that developing written roadmaps and executive support that prioritize these ideas into an organization’s most critical products is the first step to shifting towards secure software development practices. While customer input is important, the authoring agencies have observed important cases where customers have been unwilling or unable to adopt improved standards, often network protocols. It is important for the manufacturers to create meaningful incentives for customers to stay current and not allow them to remain vulnerable indefinitely.	オーサリング機関は、これらの変更がソフトウェアの使用方法に運用上の影響を及ぼす可能性があることを認識している。したがって、運用とセキュリティの考慮のバランスをとるためには、顧客の意見が重要である。機関または省庁は、これらのアイデアを組織の最も重要な製品に優先的に組み込むロードマップの作成と経営陣の支援は、安全なソフトウェア開発手法に移行するための最初のステップであると信じている。顧客の意見は重要であるが、機関 省庁は、顧客が改善された標準（多くの場合、ネットワークプロトコル）を採用したがらないか、採用できない重要な事例を観察してきた。製造者は、顧客が最新技術を採用するための有意義なインセンティブを作り、いつまでも脆弱なままにしておかないことが重要である。
HARDENING VS LOOSENING GUIDES	ハーデニング・ガイドとルースニング・ガイド
Hardening guides may result from the lack of product security controls being embedded into a product’s architecture from the start of development. Consequently, hardening guides can also be a roadmap for adversaries to pinpoint and exploit insecure features. It is common for many organizations to be unaware of hardening guides, thus they leave their device configuration settings in an insecure posture. An inverted model known as a loosening guide should replace such hardening guides and explain which changes users should make while also listing the resulting security risks.	ハーデニング・ガイドは、製品のセキュリティ管理が開発当初から製品のアーキテクチャに組み込まれていないことに起因する場合がある。その結果、ハーデニング・ガイドは、敵が安全でない機能をピンポイントで悪用するためのロードマップとなる可能性もある。多くの組織では、ハーデニング・ガイドを知らないために、デバイスの構成設定を安全でない状態のままにしておくことが一般的である。ルースニング・ガイドと呼ばれる逆モデルが、このようなハーデニング・ガイドに取って代わり、ユーザーが行うべき変更を説明し、その結果生じるセキュリティリスクも列挙する必要がある。
Rather than developing hardening guides that list methods for securing products, the authoring agencies recommend software manufacturers shift to a Secure-by-Default approach by providing loosening guides. These guides explain the business risk of decisions in plain, understandable language, and can raise organizational awareness of risks to malicious cyber intrusions. Security tradeoffs should be determined by the customers’ senior executives, balancing security with other business requirements.	機関または省庁は、製品の安全性を確保するための方法を列挙したハーデニング・ガイドを開発するのではなく、ルースニング・ガイドを提供することによって、ソフトウェアメーカーがセキュア・バイ・デフォルトのアプローチに移行することを推奨する。これらのガイドは、決定事項のビジネスリスクを分かりやすい言葉で説明し、悪意のあるサイバー侵入に対するリスクに対する組織の意識を高めることができる。セキュリティのトレードオフは、顧客の上級管理職が、セキュリティと他のビジネス要件のバランスを取りながら決定する必要がある。
RECOMMENDATIONS FOR CUSTOMERS	顧客への提言
The authoring agencies recommend organizations hold their supplying technology manufacturers accountable for the security outcomes of their products. As part of this, the authoring agencies recommend that organizational executives prioritize the importance of purchasing Secure-by-Design and Secure-by-Default products. This can manifest through establishing policies requiring that IT departments assess the security of manufacturer software before it is purchased, as well as empowering IT departments to push back if necessary. IT departments should be empowered to develop purchasing criteria that emphasize the importance of Secure-by-Design and Secure-by-Default practices (both those outlined in this document and others developed by the organization). Furthermore, IT departments should be supported by executive management when enforcing these criteria in purchasing decisions. Organizational decisions to accept the risks associated with specific technology products should be formally documented, approved by a senior business executive, and regularly presented to the Board of Directors.	機関または省庁は、組織が、供給する技術メーカーに、自社製品のセキュリティの結果について責任を負わせることを推奨する。その一環として、機関または省庁は、組織の幹部がセキュア・バイ・デザインおよびセキュア・バイ・デフォルトの製品を購入することの重要性を優先することを推奨する。これは、IT部門がメーカー製ソフトウェアを購入する前にそのセキュリティを評価することを義務付ける方針を確立することや、必要に応じてIT部門を後押しする権限を与えることで実現できる。IT部門は、セキュア・バイ・デザインとセキュア・バイ・デフォルトの重要性を強調する購買基準（本書で概説したものと組織が開発したその他のものの両方）を策定する権限を与えられるべきである。さらに、IT部門は、購買決定においてこれらの基準を実施する際に、経営陣の支援を受けるべきである。特定の技術製品に関連するリスクを受け入れるという組織の決定は、正式に文書化し、上級経営者の承認を得て、定期的に取締役会に提示する必要がある。
Key enterprise IT services that support the organization’s security posture, such as the enterprise network, enterprise identity and access management, and security operations and response capabilities, should be seen as critical business functions that are funded to align with their importance to the organization’s mission success. Organizations should develop a plan to upgrade these capabilities to leverage manufacturers that embrace Secure-by-Design and Secure-by-Default practices.	組織のセキュリティ体制を支える主要な企業向け IT サービス（企業ネットワーク、企業 ID 及びアクセス管理、セキュリティ運用及び対応機能など）は、重要なビジネス機能として捉え、組織のミッションの成功に対する重要性に応じて資金を提供する必要がある。組織は、セキュア・バイ・デザイン及びセキュア・バイ・デフォルトを採用するメーカーを活用するために、これらの機能をアップグレードする計画を策定する必要がある。
Where possible, organizations should strive to forge strategic partnership relationships with their key IT suppliers. Such relationships include trust at multiple levels of the organization and provide vehicles to resolve issues and identify shared priorities. Security should be a critical element of such relationships and organizations should strive to reinforce the importance of Secure-by-Design and Secure-by-Default practices in both the formal (e.g., contracts or vendor agreements) and informal dimensions of the relationship. Organizations should expect transparency from their technology suppliers about their internal control posture as well as their roadmap towards adopting Secure-by-Design and Secure-by-Default practices.	可能であれば、組織は主要なITサプライヤーと戦略的なパートナーシップ関係を構築するよう努めるべきである。このような関係には、組織の複数のレベルでの信頼関係が含まれ、問題を解決し、共有する優先事項を特定するための手段を提供する。セキュリティは、このような関係の重要な要素であり、組織は、関係の公式な側面（契約やベンダー契約など）と非公式な側面の両方において、セキュア・バイ・デザインとセキュア・バイ・デフォルトの実践の重要性を強化するよう努めるべきである。組織は、内部統制の態勢や、セキュア・バイ・デザインおよびセキュア・バイ・デフォルト の導入に向けたロードマップについて、テクノロジーサプライヤが透明性を確保することを期待すべきである。
In addition to making Secure-by-Default a priority within an organization, IT leaders should collaborate with their industry peers to understand which products and services best embody these design principles. These leaders should coordinate their requests to help manufacturers prioritize their upcoming security initiatives.  By working together, customers can help provide meaningful input to manufacturers and create incentives for them to prioritize security.	IT リーダーは、組織内でセキュア・バイ・デフォルトを優先することに加え、同業他社と連携して、これらの設計原則を最もよく体現している製品やサービスを理解する必要がある。これらのリーダーは、メーカーが今後のセキュリティ対策に優先順位をつけられるように、要望を調整する必要がある。 協力することで、顧客はメーカーに有意義な意見を提供し、メーカーがセキュリティを優先するためのインセンティブを生み出すことができる。
When leveraging cloud systems, organizations should ensure they understand the shared responsibility model with their technology supplier. That is, organizations should have clarity on the supplier's security responsibilities rather than just the customer’s responsibilities. Organizations should prioritize cloud providers that are transparent about their security posture, internal controls, and ability to live up to their obligations under the shared responsibility model.	クラウドシステムを活用する場合、組織は、技術サプライヤーとの責任共有モデルを確実に理解する必要がある。つまり、顧客の責任だけでなく、サプライヤーのセキュリティ責任についても明確にしておく必要がある。組織は、セキュリティ態勢、内部統制、および責任共有モデルの下で義務を果たす能力について透明性のあるクラウド・プロバイダを優先すべきである。