資料１

セキュアバイデザイン・セキュアバイデフォルトに関する
文書への共同署名に対するサイバーセキュリティ戦略本部の意見（案）について

資料１−１

セキュアバイデザイン・セキュアバイデフォルトに関する文書への共同署名に対するサイバーセキ
ュリティ戦略本部の意見（案）

資料１−２

セキュアバイデザイン・セキュアバイデフォルトに関する文書への共同署名及びこれに対するサイバーセキュリティ戦略本部の意見（案）
（概要）

資料１−３

セキュアバイデザイン・セキュアバイデフォルトに関する文書の原文（Principles Approaches
for Security-by-Design-Default）

資料１−１
セキュアバイデザイン・セキュアバイデフォルトに関する文書への共同署名に対するサイバーセキュリティ戦略本部の意見（案）
令 和 ５ 年 ○ 月 ○ ○ 日
サイバーセキュリティ戦略本部決定

米国サイバーセキュリティ・インフラ安全庁（CISA）等が策定したセキュアバイデザイ
ン、セキュアバイデフォルトに関する文書の改訂案（以下「本件文書（案）」という。）においては、セキュアバイデザインとセキュアバイデフォルトが定義された上で、これらの手法等についての、ソフトウェア作成業者やそのユーザ組織への提言等について記載されている。
我が国のサイバーセキュリティ戦略（令和３年９月 28 日閣議決定）には、「セキュリティ・バイ・デザイン」という概念が盛り込まれているところ、本件文書(案)の記載内容は、この概念を具体化したもので、サイバーセキュリティ戦略にも整合するものであり、本件文書（案）への署名は、サイバーセキュリティ戦略を踏まえた具体的な施策の推進に資するものである。
また、本件文書（案）の主な内容は、ソフトウェア作成業者が、ユーザのセキュリティ強化のために特に講じることが求められる項目をリストアップしたものであるが、いずれの項目もサイバー空間の昨今の状況変化を踏まえた妥当なものと考えられる。加えて、技術の進歩が早い分野であることから、その内容の適切性については政府側が産業界と継続的に適切な対話を重ねて改善を図っていく、という旨も明記されている。
以上を踏まえた上で、米国 CISA 等による本件文書の改訂に当たり、我が国も本件文書（案）に共同署名することについて、異存はない。

以上

資料１−２

セキュアバイデザイン・セキュアバイデフォルトに関する文書への共同署名
及びこれに対するサイバーセキュリティ戦略本部の意見（案）（概要）

内閣サイバーセキュリティセンター
令和５年10月

１

経緯

1

 米国家サイバーセキュリティ戦略（本年３月）では、能力のある行動主体（政府、
テクノロジー企業、重要インフラ事業者など）がデジタルシステムの保護に大きな責任を負うべき（「責任のリバランス」）との考え方を掲げ、セキュアバイデザ
インを強調。
 本年４月、米国サイバーセキュリティ・インフラ安全庁（CISA）は、英国、豪州、
カナダ、NZ、ドイツ、オランダのサイバーセキュリティ当局の共同署名を得て、セキュアバイデザイン、セキュアバイデフォルトに関する文書（以下、「本件文書」）を公表。
 本件文書は、セキュアバイデザインとセキュアバイデフォルトを定義し、ソフトウェア作成業者と顧客への提言を記述。法的拘束力はない。
 米国CISAから本件文書の改訂にあたり、国際協力拡大のため共同署名国を同盟国・パートナー国に拡大するところ、日本も共同署名して頂きたいとの依頼があり、関係省庁にて対応を検討。
＜参考＞ セキュアバイデザイン：IT製品（特にソフトウェア）について、安全性を確保した設計を行うこと
 セキュアバイデフォルト：ユーザー（顧客）が、追加コストや手間をかけることなく、購入後すぐにIT製品（特にソフトウェア）を安全に利用できること。新車にシートベルトが標準装備なのと類似。

２．セキュアバイデザイン・セキュアバイデフォルトに関する文書（概要）2＜定義＞ セキュアバイデザイン：IT製品（特にソフトウェア）が、設計段階から安全性を確保されていること。前提となるサイバー脅威の特定、リスク評価が不可欠。
 セキュアバイデフォルト：ユーザー（顧客）が、追加コストや手間をかけることなく、購入後すぐにIT製品（特にソフトウェア）を安全に利用できること。新車にシートベルトが標準装備なのと類似。
＜ソフトウェア作成業者などテクノロジー企業への提言＞
 セキュアバイデザイン手法の導入：①メモリに安全なプログラミング言語の採用、②アプリケーションセ
キュリティのテスト実施、③コードレビューやソフトウェア部品表（SBOM）の採用、④脆弱性の報告を奨励する開示プログラムの導入、⑤侵害をシステム全体に広げないための多層防御の導入など。
 セキュアバイデフォルト手法の導入：①デフォルトパスワードを排除する、②多要素認証を導入する、③高品質の監査ログの追加料金なしでの提供、④シングルサインオン（SSO）を実装する、⑤古いシス
テムとの互換性よりもセキュリティを優先、⑥「セキュリティ強化ガイド」の簡素化など。
 ①顧客のセキュリティの責任を顧客だけに負わせない、②徹底した透明性と説明責任を負う、③経営
層のコミットメントを得る、という3つの基本原則を遵守する。
＜ユーザ組織への提言＞
 セキュリティ結果の責任をソフトウェア作成業者に問うよう推奨する。
 セキュリティバイデザインやセキュリティバイデフォルトの製品の購入を優先する。
 ソフトウェア作成業者と戦略的な連携関係を構築。ソフトウェア作成業者への要望を調整し、セキュリ
ティを優先させる。
 クラウド利用の場合、責任分担を明確し透明性の高い企業を優先する。

３

対処方針（案）

3

 本件文書への署名は、産業界に一定程度の影響を与えることが想定される、幅広い項目を含んだ内容の文書である、また、同志国との連携・協力を内外に示すなど、関係省庁や産業界にも広く関係するもの。
 このため、本件文書について、サイバーセキュリティ戦略本部の構成員である各閣僚本部員や有識者本部員の意見を集約した上で、これをサイバーセキュリティ
戦略本部の意見として決定（持ち回り開催）し、同意見を踏まえて、NISCが署名することとしたい。
※１） 「サイバーセキュリティ戦略」（令和３年９月２８日閣議決定）に「セキュリティ・バイ・デザイン」の概念が盛り込まれているところ、原則文書の記載内容は、この概念を具体化したものであり、本件署名は同戦略を踏まえた具体的な施策の推進の一環として実施するもの。
※２） 米CISAがシンガポールで１０月１７日に公表予定であることから、同公表後、速やかに
NISCホームページにおいて本件文書を仮訳とともに公表することを想定。

４

サイバーセキュリティ戦略本部の意見（案）４ 我が国のサイバーセキュリティ戦略（令和３年９月28日閣議決定）には、「セキュリティ・バ
イ・デザイン」という概念が盛り込まれているところ、本件文書(案)の記載内容は、この概念を具体化したもので、サイバーセキュリティ戦略にも整合するものであり、本件文書（案）への署名は、サイバーセキュリティ戦略を踏まえた具体的な施策の推進に資するものである。
 また、本件文書（案）の主な内容は、ソフトウェア作成業者が、ユーザのセキュリティ強化のために特に講じることが求められる項目をリストアップしたものであるが、いずれの項目
もサイバー空間の昨今の状況変化を踏まえた妥当なものと考えられる。加えて、技術の進歩が早い分野であることから、その内容の適切性については政府側が産業界と継続的に適切な対話を重ねて改善を図っていく、という旨も明記されている。
 以上を踏まえた上で、米国CISA等による本件文書の改訂に当たり、我が国も共同署名に加わることについて、異存はない。

TLP:CLEARSHIFTING THE BALANCE OFCYBERSEC URIT Y RISK:PRI NCI PLES AN D APPROACH ES FORSECURE BY DESIGN SOFTWARETLP:CLEARTLP:CLEARCISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

2TLP:CLEARTLP:CLEAR

Contents
Overview: Vulnerable By Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
What's New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
How To Use This Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Secure by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Secure by Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Recommendations for Software Manufacturers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Software Product Security Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Principle 1: Take Ownership of Customer Security Outcomes . . . . . . . . . . . . . . . . . 11
Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Demonstrating This Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Principle 2: Embrace Radical Transparency and Accountability . . . . . . . . . . . . . . 20
Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Demonstrating This Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Principle 3: Lead from the Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Demonstrating This Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Secure by Design Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Secure by Default Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Hardening vs Loosening Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Recommendations for Customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

3TLP:CLEARTLP:CLEAROVERVIEW:VULNERABLE BY DESIGNTechnology is integrated into nearly every facet of daily life, as internet-facing systems
increasingly connect us to critical systems that directly impact our economic prosperity,
livelihoods, and even health, ranging from personal identity management to medical care.
One example of the disadvantage of such conveniences are the global cyber breaches
resulting in hospitals canceling surgeries and diverting patient care. Insecure technology
and vulnerabilities in critical systems may invite malicious cyber intrusions, leading topotential safety1 risks.
As a result, it is crucial for software manufacturers to make secure by design and secureby 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
continue to lag behind. The authoring organizations strongly encourage every technology
manufacturer to build their products based on reducing the burden of cybersecurity on
customers, including preventing them from having to constantly perform monitoring,routine updates, and damage control on their systems to mitigate cyber intrusions. We
also urge the software manufacturers to build their products in a way that facilitates
automation of configuration, monitoring, and routine updates. Manufacturers areencouraged to take ownership of improving the security outcomes of their customers.
Historically, software manufacturers have relied on fixing vulnerabilities found after thecustomers have deployed the products, requiring the customers to apply those patchesat their own expense. Only by incorporating secure by design practices will we break thevicious cycle of constantly creating and applying fixes. Note: The term “secure by design”
encompasses both secure by design and secure by default.
To accomplish this high standard of software security, the authoring organizations
encourage manufacturers to prioritize the integration of product security as a criticalprerequisite 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 lesseffort to maintain.
Reflecting this perspective, the European Union reinforces the importance of productsecurity in the Cyber Resilience Act, emphasizing that manufacturers should implement
security throughout a product‘s life-cycle in order to prevent manufacturers fromintroducing vulnerable products into the market.

1

The authoring organizations recognize that the term “safety” has multiple meanings depending on the context. For the purposesof this guide, “safety” will refer to raising technology security standards to protect customers from malicious cyber activity.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

4TLP:CLEARTLP:CLEAR

To create a future where technology and associated products are safer for customers,
the authoring organizations urge manufacturers to revamp their design and development
programs to only permit the shipping of products secure by design and default. Wellbefore development, products that are secure by design are conceptualized with thesecurity of customers as a core business goal, not just a technical feature. Secure by
design products start with that goal before development starts. Existing products canevolve to a secure by design state over multiple iterations. 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, thesetwo philosophies move much of the burden of staying secure to manufacturers andreduce the chances that customers will fall victim to security incidents resulting frommisconfigurations, insufficiently fast customer patching, or many other common issues.
The Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency(NSA), Federal Bureau of Investigation (FBI) and the following international partners2
provide the recommendations in this guide as a roadmap for software manufacturers toensure security of their products:» Australian Cyber Security Centre (ACSC)» Canadian Centre for Cyber Security (CCCS)» United Kingdom’s National Cyber Security Centre (NCSC-UK)» *HUPDQ\·V)HGHUDO2IÀFHIRU,QIRUPDWLRQ6HFXULW\ %6,» Netherlands’ National Cyber Security Centre (NCSC-NL)» Norway’s National Cyber Security Center (NCSC-NO)» Computer Emergency Response Team New Zealand (CERT NZ) and New Zealand’s National
Cyber Security Centre (NCSC-NZ)» .RUHD,QWHUQHW 6HFXULW\$JHQF\ .,6$
» ,VUDHO·V1DWLRQDO&\EHU'LUHFWRUDWH ,1&'
» -DSDQ·V1DWLRQDO&HQWHURI,QFLGHQW5HDGLQHVVDQG6WUDWHJ\IRU&\EHUVHFXULW\ 1,6& DQG
Japan Computer Emergency Response Team Coordination Center (JPCERT/CC)» 2$6&,&7(1HWZRUNRI*RYHUQPHQW&\EHU,QFLGHQW5HVSRQVH7HDPV &6,57 $PHULFDV» Cyber Security Agency of Singapore (CSA)» &]HFK5HSXEOLF·V1DWLRQDO&\EHUDQG,QIRUPDWLRQ6HFXULW\$JHQF\ 1Ó.,%The authoring organizations recognize the contributions by many private sector partners
in advancing security by design and security by default. This product is intended toprogress an international conversation about key priorities, investments, and decisions
necessary to achieve a future where technology is safe, secure, and resilient by designand default. To that end, the authoring organizations seek feedback on this product frominterested 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.

2

Hereafter referred to as the “authoring organizations.”

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

5

TLP:CLEARTLP:CLEAR

WHAT’S N EW
The initial publication of this report generated a significant amount of conversation within
the software industry. Daily news of organizations and individuals being compromised
highlights the need for more conversation regarding how to address chronic and systemic
problems in software products.
After the release in April 2023, the authoring organizations (henceforth referred to as “we”
and “our”) received thoughtful feedback from hundreds of individuals, companies, andtrade associations. The most common request in the feedback was to provide more detailon the three principles as they apply to both software manufacturers and their customers.
In this document, we expand on the original report and touch on other themes such as
manufacturer and customer size, customer maturity, and the scope of the principles.
Software is everywhere and no single report will be able to adequately cover the entire
range of software systems, development of software products, customer deployment andmaintenance, and integration with other systems. For guidance below that does not clearly
map to a particular environment, we look forward to hearing from the community how thepractices described in this paper led to particular security improvements.
This report applies to manufacturers of artificial intelligence (AI) software systems andmodels as well. While they might differ from traditional forms of software, fundamental
security practices still apply to AI systems and models. Some secure by design practices
may need modification to account for AI-specific considerations, but the three overarching
secure by design principles apply to all AI systems.
We recognize that transforming a software development lifecycle (SDLC) to align withthese secure by design principles is not a simple task and may take time. Further, smaller
software manufacturers may struggle to implement many of these suggestions. We believethat the software industry needs to make widely available the tools and procedures thatmake products safer. As more people and organizations focus their attention on software
security improvements, we believe there is room for innovations that will narrow the gap
between larger and smaller software manufacturers to the benefit of all customers.
This update to the original secure by design report is part of our commitment to build
partnerships with the many interconnected stakeholder communities that underpin
our technological ecosystem. It is the result of feedback from many parts of that
ecosystem, and we will continue to listen and learn from perspectives. Although there
are many challenges ahead, we are incredibly optimistic as we learn more about people
and organizations that have already adopted a secure by design philosophy, often withsuccess.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

6

TLP:CLEARTLP:CLEARE

HOW TO USE THIS DOCUMENT
We urge software manufacturers to adhere to the principles within thisdocument. Software manufacturers can demonstrate their commitment by
publicly documenting their actions taken, in line with the steps listed below.
We encourage software manufacturers to find tactics that meet the spirit ofthese principles and to create artifacts that will build a compelling case to evenskeptical current and potential customers that they are embodying the secureby design philosophy.
In addition to actions software manufacturers should take, customers canalso leverage this document. Companies buying software should ask hardquestions of their vendors, drawing inspiration from the examples of adheringto the principles listed in this document. In doing so, customers can help toshift the market towards products that are more secure by design. An exampleof questions customers can ask of vendors is given in CISA’s Guidance for K-12
Technology Acquisitions.
We encourage enterprise customers to incorporate these practices into
procurement processes, vendor due diligence assessments, enterpriserisk acceptance decisions, and other steps taken when evaluating vendors.
Customers should also push their vendors to publicly document the secure by
design actions each vendor takes. Collectively, this can create a strong demand
signal for security, which can encourage and enable software manufacturers totake steps towards greater security. In other words, just as we seek to create apervasive secure by design philosophy within software manufacturers, we needto create a “secure by demand” culture with their customers.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

7

TLP:CLEARLEE

Secure by Design

TLP:CLEAR“Secure by design” means that technology products are built in a waythat 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 enumerateprevalent 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 malicious actors from compromising systems or obtaining
unauthorized access to sensitive data. The authoring organizations further
recommend manufacturers use a tailored threat model during the productdevelopment stage to address all potential threats to a system and accountfor each system’s deployment process.
The authoring organizations urge manufacturers to take a holistic security
approach for their products and platforms. Secure by design development
requires the strategic investment of dedicated 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 businesspriority, not just a technical feature. This collaboration between businessleaders and technical teams extends from the preliminary stages of designand development, through customer deployment and maintenance.
Manufacturers are encouraged to make hard tradeoffs and investments,
including those that will be “invisible” to the customers (e.g., migrating toprogramming languages that eliminate widespread vulnerabilities). They
should prioritize the features, mechanisms, and implementation of toolsthat 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 existingproduct portfolios with more secure by design practices, ensuring to only
deviate in exceptional situations.
The authoring organizations acknowledge that taking ownership of the
security outcomes for customers and ensuring this level of customer
security may increase development costs. However, investing in secureby design practices while developing innovative technology products andmaintaining existing ones can substantially improve the security postureof customers and reduce the likelihood of compromise. Secure by designprinciples not only strengthen the security posture for customers andbrand reputation for developers but the practice also lowers maintenanceand patching costs for manufacturers in the long term.
The Recommendations for Software Manufacturers section listed
below provides a list of product development practices and policies for
manufacturers to consider.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

8

TLP:CLEAR

Secure by Default

TLP:CLEAR“Secure by default” means products are resilient against prevalent
exploitation techniques out of the box without added charge. These
products protect against the most prevalent threats and vulnerabilities
without end-users having to take additional steps to secure them. Secureby default products are designed to make customers acutely aware thatwhen they deviate from safe defaults, they are increasing the likelihoodof compromise unless they implement additional compensatory controls.
Secure by default is a form of secure by design.
» $VHFXUHFRQÀJXUDWLRQVKRXOGEHWKHGHIDXOWEDVHOLQH6HFXUHE\GHIDXOW
products automatically enable the most important security controls
needed to protect enterprises from malicious cyber actors, as well as
VXSSO\WKHDELOLW\WRXVHDQGIXUWKHUFRQÀJXUHVHFXULW\FRQWUROVDWQR
additional cost.
» 7KHFRPSOH[LW\RIVHFXULW\FRQÀJXUDWLRQVKRXOGQRWEHDFXVWRPHUSUREOHP2UJDQL]DWLRQDO,7VWDIIDUHIUHTXHQWO\RYHUORDGHGZLWKVHFXULW\DQG
operational responsibilities, thus resulting in limited time to understand
DQGLPSOHPHQWWKHVHFXULW\LPSOLFDWLRQVDQGPLWLJDWLRQVUHTXLUHGIRUD
UREXVWF\EHUVHFXULW\SRVWXUH0DQXIDFWXUHUVFDQDLGWKHLUFXVWRPHUVE\
RSWLPL]LQJVHFXUHSURGXFWFRQÀJXUDWLRQ³VHFXULQJWKH´GHIDXOWSDWKµ³
ensuring their products are manufactured, distributed, and used securelyin accordance with “secure by default” standards.
Manufacturers of products that are “secure by default” do not charge
extra for implementing added security configurations. Instead, they
include them in the base product like seatbelts are included in all new cars.

Security should not be a luxury option, butshould be considered a right customers receive
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 authoringorganizations 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.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

9TLP:CLEARTLP:CLEAR

SOFTWARE PRODUCT SECURITY
PRINCIPLES
Software manufacturers are encouraged to adopt a strategic focus that prioritizes software security.
The authoring organizations developed the following three core principles to guide software
manufacturers in building software security into their design processes prior to development,
conﬁguration, and shipment of their products.

1

2

3

Take ownership of customer security outcomes and evolve products
accordingly. The burden of security should not fall solely on the customer.

Embrace radical transparency and accountability.
Software manufacturers should pride themselves in delivering safe and secure
products, as well as differentiating themselves from the rest of the manufacturer
community based on their ability to do so. This may include sharing information theyOHDUQIURPWKHLUFXVWRPHUGHSOR\PHQWVVXFKDVWKHXSWDNHRIVWURQJDXWKHQWLFDWLRQPHFKDQLVPVE\GHIDXOW,WDOVRLQFOXGHVDVWURQJFRPPLWPHQWWRHQVXUHYXOQHUDELOLW\advisories and associated common vulnerability and exposure (CVE) records arecomplete and accurate. However, beware 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.
Build organizational structure and leadership to achieve these goals.
While technical subject matter expertise is critical to product security, senior executives
DUHWKHSULPDU\GHFLVLRQPDNHUVIRULPSOHPHQWLQJFKDQJHLQDQRUJDQL]DWLRQExecutives need to prioritize security as a critical element of product development
across the organization, and in partnership with customers.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

10

TLP:CLEARTLP:CLEAR

To enable these three principles, manufacturers should consider several operational
tactics to evolve their development processes.
Convene routine meetings with company executive leadership to drive the importanceof secure by design and secure by default within the organization. Policies andprocedures 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 that directly link software security standards
and manufacturer accountability. Manufacturers should ensure they have robust,
independent product security assessment and evaluation programs for their products.
Use a tailored threat model during resource allocation and development to prioritize
the most critical and high-impact features. Threat models consider a product’s specificuse-case and enable development teams to fortify products. Finally, senior leadershipshould hold teams accountable for delivering secure products as a key element of
product excellence and quality.
As part of the October 2023 update to this guidance, these three principles are
expanded upon through the following explanations, demonstrations, and evidence.

PRINCIPLE 1: Take Ownership ofCustomer Security Outcomes
EXPLANATION
Modern best practices dictate that software manufacturers invest in productsecurity efforts that include application hardening, application features, andapplication default settings.
Software manufacturers need to implement application hardening by using
processes and technologies that raise the cost for a malicious actor wishing tocompromise applications. Application hardening protocols and procedures help
products resist attacks by intelligent malicious actors. Terms like hardening, productsecurity, and resilience are all closely related to product quality. The idea is that
security must be “baked in,” and not “bolted on.” [1] By baking in security, software
manufacturers can not only increase their customers’ security but also increase
their products’ quality. Sample tactics include ensuring user input is validated
and sanitized, and isn’t entered directly into code (i.e., by using parameterized
queries instead), using a memory safe programming language, rigorous softwaredevelopment life cycle (SDLC) management, and using hardware-backed
cryptographic key management.
Applications need to support application features that relate to cybersecurity.
Sometimes called “capabilities,” these features extend the functionality of a productor service in ways that help maintain or increase the security posture of a customer.
CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

11T
TLP:CLEARTLP:CLEAR
T

Sample security-related features include supporting transport layer security (TLS) for all
network connections, single sign on (SSO) support, multi-factor authentication (MFA)
support, security event audit logging, role-based access control (RBAC), and attributebased access control (ABAC).
Some of these product features are configurable allowing customers to moreeasily integrate the product into their existing environments and workflows. Those
configurations mean applications must have default settings set until customers
configure them. Those default settings need to be set securely “out of the box” so that
customers expend fewer resources to make their stack of technology products moresecure.
Each of these elements – application hardening, application security features, andapplication default settings – plays a role in the security of the application, and theresulting security posture of the customer. Software manufacturers should think about
each of these elements and how they relate to each other. Manufacturers should
think about more than just their investments to incorporate these elements into theirproducts. Manufacturers should take it a step further and consider how those elementschange the real-world security posture of their customers, for better or for worse.
Manufacturers should take ownership of their customers’ security outcomes rather than
measuring themselves solely on their efforts and investments. The responsibility shouldbe placed upstream, with the manufacturers, where it has the greatest likelihood of
reducing the chances of compromise.
Unfortunately, that’s not the case today. Too many manufacturers place the burden of
security on the customer rather than investing in comprehensive application hardening.
For example, when the manufacturer patches one vulnerability, we often see similar
vulnerabilities exposed because they addressed the symptom rather than the root causeof that defect. The product might implement different mitigations in various parts of thecode base for the same class of vulnerability. As a case in point, after the manufacturer
fixed one input sanitization vulnerability, researchers or attackers found code paths that
did not benefit from the improved input sanitization. The manufacturer applied fixes one
at a time rather than unifying the codebase to eliminate that class of vulnerability acrossthe entire application.
Application features can create both benefits and risk for customers. Features thatallow integration points with many external systems and versions can greatly increase
the value of a product. And yet supporting features without a retirement plan, like a
networking protocol, can leave customers vulnerable if they lack an understanding of theimplications of ongoing use of that feature. For example, some products continue to use
networking protocols that have their origins in the 1990s or 2000s and are now known
to be unsafe. There are numerous factors that can slow how fast customers upgradeand deploy modern security measures. They may use products that integrate with therest of the organization’s network, but lack modern security measures, preventing the ITteam from modernizing. Still, software manufacturers can factor these patterns into theirplanning process to encourage customers to stay current.
Application default settings are an added area of potential risk for customers.
Manufacturers often choose certain default settings, making it easier for customers
to use the application features they want. The downside is that this practice increases
the attack surface for customers who may not need certain features and protocols thatare enabled by default. Additionally, many security controls are toggled off by default or
require customers to take time to configure their settings to increase security. Explicit
threat modeling is a tactic that may help inform the decision of which features should beon by default or which settings are needed to be secure by default. Another tactic is toinvestigate ways to make features more discoverable for the administrator.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

12T
TLP:CLEARTL

TLP:CLEAR

Some manufacturers ship products with defaults that can create risk for some or all theircustomers. Rather than set safer defaults, they often opt to produce a hardening guidethat customers must implement at their own expense. Hardening guides suffer from several
common problems. Some hardening guides are hard to find and are not well supported.
Others are complex to implement, occasionally requiring software development to write an
extension module. Still, others assume the reader has extensive cybersecurity experience
to understand the ways in which various settings change the attack surface. Practitioners
who have an incomplete understanding of the ways in which attackers work may fail toproperly implement hardening guide instructions, especially if the instructions do not makethe trade offs clear. Further, not all hardening guides are written by engineers who are
intimately familiar with attacker tactics and economics, causing them to create hardening
guides that are ineffective even if faithfully implemented. Millions of customers are taking
on the responsibility to harden multiple instances of software or systems, often in resourceconstrained environments. Relying on hardening guides simply doesn’t scale.
An application’s settings should be continuously evaluated whether the settings were thedefault or set by the customer, against the manufacturer’s current understanding of thethreat landscape. Applications should be made with clear indicators about the potential
risks that may result from those settings and should make those indicators known. Just likea modern car has an indicator about seatbelts and expresses that indicator by soundingan alert if you try to drive without buckling up, software should express indicators about
the state of security of a system. If an application is configured to not require MFA for
administrator accounts, it should make the administrators regularly aware that they andtheir entire organization are in danger if they do not configure MFA. Additionally, if anapplication is configured to support older protocols that are now known to implement weak
cryptography, it should regularly make it clear to the administrators that the organization
is in danger and provide resources to resolve the situation. We urge manufacturers
to implement routine nudges that are built into the product rather than relying on
administrators to have the time, expertise, and awareness to interpret hardening guides.
Opportunities clearly exist for innovation to balance security and usability considerations.
Each of the above elements creates an untenable situation in which customers needto research, fund, purchase, staff, deploy, and monitor additional security products to
reduce the chance of compromise. Small and medium sized organizations (SMOs) are
generally unable to facilitate these options. They face scarcity in expertise, funding, andtime which taxes bandwidth and function, forcing security to a lower priority, and, in theaggregate, exacerbates collective risk. Conversely, security investments by the relative
few manufacturers will scale. A common phrase that summarizes the problem is that thesoftware industry needs more secure products, not more security products. Software
manufacturers should lead that transformation.

The software industry needs more secure
products, not more security products. Software
manufacturers should lead that transformation.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

13

TLP:CLEARTLP:CLEAR

Today, we sometimes read comments from manufacturers explaining that a customer
was compromised due to not enabling a particular security feature or following specifichardening guidance. Instead, after a compromise, manufacturers should explain whether
a particular security feature or specific hardening guidance would have prevented thecompromise and consider making it the default at no charge. In those cases where theproduct itself was not sufficiently hardened in the design and implementation phases, themanufacturer should explain how they are working to eliminate that class of vulnerability
from their product lines.
Software manufacturers have a responsibility to ensure that their products are designed
and developed with security as a top priority. To that end, they should objectively measure
the results of their efforts in the field. We call on manufacturers to not just focus on
their internal efforts, but to objectively measure and regularly report the results andeffectiveness of a product’s security efforts and configurations, and to build a feedback
loop that creates changes in the SDLC that lead to measurable improvements in customer
safety and more secure products. Reporting should include anonymized data that theacademic and security research community could use to track high-level trends andmeasure progress ecosystem wide.

DEMONSTRATING THIS PRINCIPLE
Software manufacturers and online services should find ways to demonstrate successes in
implementing this principle. They should seek to provide evidence in the form of artifacts
for outsiders to examine. No single artifact by itself will prove that a manufacturer isimplementing a robust secure by design program, but by providing various artifacts they
will build a case of the manufacturer’s commitment to developing secure products. Thisapproach is in the spirit of “show, rather than tell.”To demonstrate this principle, software manufacturers should consider steps suchas those in the following list. The authoring organizations recognize that few software
manufacturers will be able to immediately implement these practices and produce
corresponding artifacts at the start of their secure by design journey. Further, software
manufacturers will need to prioritize this list depending on how the customers deploy the
product in the field to achieve the largest security benefits.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

14

TLP:CLEARTLP:CLEART

SECURE BY DEFAULT PRACTICES

1. Eliminate default passwords. Default
passwords continue to be implicated as
the cause of many attacks every year.
Making a commitment to eliminate thischronic problem will deny easy accessto attackers. Similarly, manufacturers
should consider what password practices
should be implemented, such as minimum
password length and disallowing known
breached passwords.

2. Conduct field tests. As technology
continues to evolve and become more
complex, it is increasingly importantfor software manufacturers to conduct
security-centric user testing tounderstand their products’ security
posture in the field. Similar to how user
research informs software development
requirements, software manufacturers
should also conduct security-focuseduser research to understand where thesecurity user experience (UX) falls short.
By observing how customers deploy
and use their products in real-world
environments, software manufacturers
can gain valuable insights into the usability
and effectiveness of their security
features and controls. These insights canhelp identify areas for improvement andrefine their products to better meet the
security needs of customers. For example,
field tests might suggest changes in UX
flow, defaults, alerting, and monitoring.
Field tests may also show where past
improvements in the product’s design
reduce the velocity of security patches,
reduce configuration errors, and minimize
attack surface.

Manufacturers should consider
the following:•

Do customers correctly implement thehardening guide?

•Do the product’s existing security features
perform as expected in the field?

•

Do those features actually resist real-world
attacks?

•

Which features would better reduce the likelihoodof compromise?
Note: To gain deeper insights into theseelements, software manufacturers may wish
to partner with customers to conduct redteam exercises to see how the product resists
attacks. These field tests might take place at thecustomer’s physical site, virtually, or via telemetry
from the application in a privacy-preserving
manner.

3. Reduce hardening guide size. Manufacturers
can improve customers’ security posturesby streamlining or even eliminating producthardening guides and focusing on the mostcritical security measures that customers
should prioritize when deploying their products.
Rather than overwhelming customers with alaundry list of security measures, manufacturers
should identify the top security risks that theirproducts are susceptible to and provide clear
and concise guidance on how to mitigate theserisks. In addition, manufacturers should provide
customers with tools and automation that simplify
the process of implementing security controls,
such as scripts that can easily be deployed intheir environment. These tools should additionallybe able to verify and clearly show the changes
made from the original baseline. By streamlining
hardening guides and providing customers witheasy-to-use tools and automation, manufacturers
can reduce the burden on their customers andhelp ensure that their products are deployed in asecure manner. One tactic would be to consider
implementing the Pareto principle to reduce thenumber of steps for the common use cases (the80%), and then providing contextual guidance andtooling for less common scenarios (the 20%). In
this way, software manufacturers will be making

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

15

T
TLP:CLEARTLP:CLEAR

the simple things simple, and the hard things possible.
Field testing will be a powerful tool in measuring how longit takes customers to discover, understand, and implement
hardening guides. Manufacturers should consider how the
product could nudge administrators to take action within
the product itself rather than relying on them to implementtasks from a hardening guide.
4. Actively discourage use of unsafe legacy features.
Prioritize security through clear upgrade paths overbackwards compatibility. Publish blog posts showing the
adoption of safer features and protocols, and deprecate
unsafe features by announcement, possibly from within
the product itself. A significant number of customers
have demonstrated that they will not keep their systems
current with modern network, identity, and other criticalsecurity features. In some cases, customers fear existing
functionality will break with an upgrade. By making
upgrades as seamless as possible, customers will likely
upgrade and get security fixes more often and quickly.
Software manufacturers should aggressively nudge
customers along upgrade paths that reduce customer risk.
5. Implement attention grabbing alerts.
Similar to seat belt chimes in cars that continuously makenoise when seat belts are not fastened, manufacturers
should implement timely and repeated alerts whenusers or admins are in truly unsafe states, warning
administrators that they are using deprecated protocols intheir environments and suggest upgrade paths. Implement
timely and repeated alerting when users or admins, or theapplication configuration, are in an unsafe state. Make theunsafe mode clear to the administrators on a regular basis.
An additional feature could require a super administrator
to acknowledge the lack of MFA on their account uponeach login, or even disable certain key features until they
enable MFA. There is room to innovate to achieve thesegoals while not creating alert fatigue.
6. Create secure configuration templates.
These templates can pre-set certain configurations tosafe settings based on an organization’s risk appetite.
While it might be overly simplistic to have low/medium/high security templates, that example illustrates how
many settings could be updated to manage risk for theorganization. Templates can be supported by hardening
guides on the risks the manufacturer has identified.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

16

TLP:CLEARTLP:CLEART

SECURE PRODUCTDEVELOPMENT PRACTICES
1. Document conformance to asecure SDLC framework. Secure
SDLC frameworks provide objectives
and examples across people, processes,
and technologies. Consider publishing adetailed description of which secure SDLC
framework controls have been implemented
and describe any alternate controls
which have been used. Within the US,
consider using the NIST Secure Software
Development Framework (SSDF). While
not a checklist, the SSDF “describes a setof fundamental, sound practices for secure
software development.”

2. Document Cybersecurity Performance
Goals (CPG) or equivalentconformance. When an organization
attests that they conform to the NIST SSDF
standard, they are asserting that their
SDLC is informed by well-understood bestpractices. However, it is not sufficient forthem to only have a robust SDLC. They alsoneed to protect their own enterprise anddevelopment environments from malicious
actors who would seek to manipulate thesecurity properties of the product while
it is still in development. This is not atheoretical class of attack, but one thathas been carried out with adverse effects
to customers, and by extension national
security. Organizations should consider
publishing details on the organization’s
conformance to the CISA CPGs, the NIST
Cybersecurity Framework (CSF), or othercybersecurity program frameworks.
3. Vulnerability management. Somemanufacturers have a vulnerability
management program that focuses onpatching vulnerabilities discovered internallyor externally, and little more. More mature
programs incorporate extensive datadriven analysis of vulnerabilities and theirroot causes, taking steps to systemically3eliminate entire classes of vulnerability3 . They
implement formal programs around setting quality
planning, quality control, quality improvement,
and quality measurement. They view defectmanagement as a business matter, not merely asecurity matter. These programs are not dissimilar
in some ways to quality and safety programs inother industries.
4. Responsibly use open source software.
When open source software is used,
be responsible by vetting open source
packages, fostering code contributions backto dependencies, and helping sustain thedevelopment and maintenance of criticalcomponents. For reference, Japan’s Ministryof Economy, Trade, and Industry (METI) has
published "Collection of Use Case Examples
Regarding Management Methods for Utilizing
OSS and Ensuring Its Security."
5. Provide secure defaults for developers.
Make the default route during softwaredevelopment the secure one by providing safebuilding blocks for developers. For example, given
the prevalence of SQL injection vulnerabilities
causing real-world harm, ensure that developers
use a well-maintained library to prevent that classof vulnerability. Also known as “paved roads” or“well-lit paths,” this practice ensures both speed
and security, and reduces human error.
6. Foster a software developer workforce that
understands security. Ensure that your softwaredevelopers understand security by training themon secure coding best practices. Further, helptransform the broader workforce by updating
hiring practices to evaluate security knowledge
and working with universities, community
colleges, bootcamps, and other educators
to weave security into computer science andsoftware development curriculums.

1,6766')32([DPSOH´'HÀQHSROLFLHVWKDWVSHFLI\WKHVHFXULW\UHTXLUHPHQWVIRUWKHRUJDQL]DWLRQ·VVRIWZDUHDQGYHULI\FRPSOLDQFH
DWNH\SRLQWVLQWKH6'/& HJFODVVHVRIVRIWZDUHÁDZVYHULÀHGE\JDWHVUHVSRQVHVWRYXOQHUDELOLWLHVGLVFRYHUHGLQUHOHDVHGVRIWZDUH µCISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

17

T
TLP:CLEARTLP:CLEAR

7. Test security incident event management (SIEM) and security orchestration, automation,and response (SOAR) integration. In addition to conducting field tests, work jointly withpopular SIEM and SOAR providers in conjunction with select customers to understand how
incident response teams use logs to investigate suspected or actual security incidents. Few
software developers have experience responding to an incident and may create log entries that
don’t help responders as much as they would expect. By working both with SIEM and SOAR
technologies and real incident response professionals, the development team can create
logs that tell the correct and complete story, saving time and reducing uncertainty during an
incident.
8. Align with Zero Trust Architecture (ZTA). Align product deployment guides with, for example,
the NIST ZTA models and the CISA Zero Trust Maturity Model. Encourage customers toincorporate these principles in their environments.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

18

TLP:CLEARTLP:CLEAR
T

PRO-SECURITY BUSINESS PRACTICES

1. Provide logging at no additional charge.
Cloud services should commit to generating
and storing security-related logs at no
additional charge. On-premises products
should likewise generate security-related
logs at no additional charge. Further,
the product should log security events
by default since many customers may
not understand their value until after anincident. These tactics may require athorough review of what security eventsshould be logged to provide cybersecurity
state awareness, how a customer may
configure logging, for what time period
logs are retained, how log integrity andstorage are protected, and how logs can beanalyzed. In some cases, the review may
suggest the need for a refactoring of theapplication’s log management architecture
to help make them actionable and at a costthat works for the manufacturer. Working
with incident response (IR) experts canincrease the chances that the logs will be
useful to investigators in the field. See thesection on SIEMs.

arguments ignore the fact that few customers
will call to complain or bargain, not all customers
actually understand what the benefits of thesefeatures are, and that all features cost something
to maintain. Yet we don’t see many manufacturers
charging extra for availability or data integrity. The
costs to support those key attributes are built into
the price all customers pay, much like the costs toinclude seatbelts, collapsible steering columns,
and airbags that save lives in accidents.
3. Embrace open standards. Implement open
standards, especially around common network
and identity protocols. Avoid proprietary protocols
when open standards are available.
4. Provide upgrade tooling. Many customers
are reluctant to adopt the latest version of the
product, including deploying newer and moresecure features like secure network connections.
Software manufacturers can increase customer
adoption of new upgrades by providing toolingto help reduce uncertainty and risk. Offer
free licenses for customers to test upgradesand patches in a test environment as a way tomotivate customers.

2. Eliminate hidden taxes. Publish acommitment to never charge for security
or privacy features or integrations. For
example, within the larger scope of identityand access management (IAM), there
are services called single sign-on (SSO)
services. Some manufacturers charge more
to connect their system to a SSO service(sometimes referred to as an identity
provider). This “SSO tax” means that good
identity and access management is out ofreach for many SMOs, preventing themfrom achieving a strong security posture.
Some services charge more to enable MFA
for users. Security should not be priced asa luxury good but considered a customer
right. Some manufacturers have argued
that few customers request these features,and they cost more to maintain. TheseCISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

19

T
TLP:CLEARTLP:CLEAR

PRINCIPLE 2: Embrace Radical
Transparency and Accountability
EXPLANATION
Software manufacturers should pride themselves in delivering safe and secure
products, as well as differentiating themselves from the rest of the manufacturer
community based on their ability to do so.
Let’s address a common concern about transparency. When practitioners discuss
radical transparency, there is a tendency for the conversation to get bogged down
in a concern that they are providing a “roadmap for attackers.” However, theoverwhelming evidence is that attackers are doing just fine without such roadmaps,
and such concerns should take a back seat to transparency that benefits direct
customers, indirect customers, supply chains, and the entire software industry.
Transparency helps the industry establish conventions—in other words, what “good”
looks like. It helps those conventions change over time in response to customer
needs, changes in threat actor tactics or economics, or technology evolution.
Transparency helps manufacturers with fewer resources learn from those with moremature and capable resources. Conversations about information sharing should
expand beyond real-time threat indicators, to include the elements below.
Transparency forces decisions around security to be made early in the development
process, and to be a continuous activity of business leaders as well as engineers and

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

20

T
TLP:CLEARTLP:CLEAR
T

security professionals. Transparency builds accountability into the product.
A note on the choice of the adjective “radical” in front of “transparency.” Today, it
is uncommon for software manufacturers to publish detailed information about
how they develop and maintain software and how they mature their programs
using data over time. In the software industry, few manufacturers offer guided
tours of how they design their software. There are few opportunities for software
manufacturers to see how peer organizations structure their SDLC programs, andhow those programs hold up in the customer environments against real attackers.
The collective industry would benefit from more information sharing on topics suchas strategies to measure the cost of security defects and to eliminate classes ofvulnerability. As a result of these common practices, every software manufacturer
must learn how to deal with product security on their own. Perhaps by not placing aluxury tax on security features, safety and security therefore become a cost center
rather than a profit center, and companies would benefit by lightening the load
through collaboration and transparency.
We want to focus on the tactics that will materially accelerate the evolution of thesoftware industry. We can no longer afford to make opportunistic, incremental
improvements. If we are to collectively overcome the threats posed by intelligent
and adaptive adversaries, we must embrace levels of transparency that will
feel uncomfortable today, but that will drive the industry forward. There are
manufacturers today who embody some of these secure by design principles.
As William Gibson said, “the future is already here, it’s just not very evenly
distributed.” Radical transparency will help distribute that information andbenefit the defenders more than our adversaries.
Transparency can do more than help peer organizations mature their SDLCs.
Prospective customers and investors can learn more about the investments andtradeoffs manufacturers have made, and the security posture those investments
have created for customers. Manufacturers who embrace radical transparency will
give customers information to help them make purchasing decisions not just on
price and features, but on security as well.
As hard as organizations work to secure their supply chain and their SDLC,
companies have had their builds processes compromised in the recent past.
Embracing radical transparency should lead to public disclosure of the attack as
well as the improvements the company made to prevent and detect future attacks.
That form of information sharing will help other organizations learn without having
to suffer the same fate.

DEMONSTRATING THIS PRINCIPLE
To demonstrate this principle, software manufacturers should take steps including
the following:

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

21

T
TLP:CLEARTL

TLP:CLEARSECURE BY DEFAULT PRACTICES

1. Publish aggregate security relevant statistics and trends. Example topics include
MFA adoption by customers and administrators and use of unsafe legacy protocols.
2. Publish patching statistics. Detail what percent of customers are on the latest versionof the product, and what you are doing to make updates easier and more reliable.
3. Publish data on unused privileges. Publish aggregate information on excessive
permissions across your customer base as well as the nudges and other changes tothe product you are making to reduce the customers’ attack surfaces. These unused
privileges are likely to be good candidates for administrator alerts, like seatbelt chimes.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

22

TLP:CLEARTLP:CLEART

SECURE PRODUCTDEVELOPMENT PRACTICES
1. Establish internal security controls.
Many companies have seen the benefits ofmoving their data to cloud providers. Now
those cloud providers become the targetof attackers. Software as a Service (SaaS)
providers should publish statistics oftheir internal controls. For example, SaaS
providers should publish statistics on theirinternal deployment of phishing-resistant
MFA, like Fast Identity Online (FIDO)
authentication. Ideally, they should be able
to say that no staff member can accesscustomer or other sensitive data withoutauthenticating via phishing-resistant MFA.
2. Publish high-level threat models.
Secure by design products start withwritten threat models that describe
what the creators are trying to protect
and from whom. Effective threat models
are informed by the way intrusions
happen in the wild, and should coverboth the enterprise and development
environments, as well as the way thesoftware manufacturers intend for it to be
used in customer environments.
3. Publish detailed secure SDLC selfattestations. Manufacturers following
NIST SSDF, or other similar frameworks
are actively working towards a mature
software development lifecycle. Publishinga self-attestation of which controls the
manufacturer has enacted, and forwhich products, would demonstrate acommitment to adhering to these bestpractices and provide an increased levelof confidence to their customers. Other
certification schemes include the Israel
Cyber Supply Chain Methodology, forinstance.
4. Embrace vulnerability transparency.
Publish a commitment that will ensurethat identified product vulnerabilities

will be published as CVE entries that are
correct and complete. That’s especially true
for the common weakness enumeration
field that identifies the root cause of thevulnerabilities. The more correct andcomplete the public CVE database is, themore the industry can track how products
are becoming more secure, and whichclasses of vulnerabilities are most prevalent.
However, beware of the temptation tocount CVEs as a negative metric, sincesuch numbers are also a sign of a healthycode analysis and testing community. As
manufacturers implement a secure by
design philosophy, it’s possible that at
first their raw CVE count will go up due
to more comprehensive discovery andremediation of vulnerabilities in existingcode. Manufacturers should publish
analysis of past vulnerabilities, including any
patterns and measures that were taken toaddress the entire class of vulnerabilities.
For example, if a large percentage of acompany’s CVEs were related to crosssite scripting (XSS), documenting the root
cause analysis, response (such as shifting
to web template frameworks that prevent
XSS), and results would signal to customers
that they will not be victimized by a class ofvulnerability for which mitigations have been
understood for decades.
5. Publish Software Bills of Materials(SBOMs). Manufacturers shouldhave command of their supply chains.
Organizations should build and maintain
SBOMs [2] for each product, request datafrom their suppliers, and make SBOMs
available for downstream customers andusers. This will help demonstrate theirdiligence in understanding the components
they use in the creation of their products,
their ability to respond to newly identified
risks, and can help customers understandhow to respond if one of the modules in the
supply chain has a newly found vulnerability.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

23

T
TLP:CLEARTLP:CLEARA

For reference, Japan’s Ministry of Economy, Trade, and Industry (METI) has published“Guide of Introduction of Software Bill of Materials (SBOM) for Software Management.”
Transparency should extend to firmware in embedded devices and the data and models
used in AI/machine learning (ML). Beyond assisting in purchasing decisions andoperational capabilities, SBOMs play an important role in the infrastructure to detect
and respond to malicious supply chain attacks.
6. Publish a vulnerability disclosure policy. Publish a vulnerability disclosure policy that
(1) authorizes testing against all products offered by the manufacturer and conditions
for those tests, (2) provides legal safe harbor for actions performed consistent withthe policy, and (3) allows public disclosure of vulnerabilities after a set timeline.
Manufacturers should perform root-cause analysis of discovered vulnerabilities and, tothe greatest extent feasible, take actions to eliminate entire vulnerability classes. See
CISA’s Vulnerability Disclosure Policy Template for reference language.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

24

TLP:CLEART
TLP:CLEAR

PRO-SECURITY BUSINESSPRACTICES
1. Publicly name a secure by design senior
executive sponsor. In many organizations,security (like quality) is delegated totechnical teams who have limited ability tomake structural changes to dramatically
improve the security of the products.
Publicly naming a top business executive tooversee the secure by design program willtransform the security of products into a
top-level business concern.
2. Publish a secure by design roadmap.
Manufacturers should document changes
made to their SDLC to improve customer
security, including details about fieldtest reports, actions taken to eliminate
entire classes of vulnerability, and otheritems listed in the other principles. As in
the case of quality improvement efforts,
security improvement programs havedistinct phases of planning, control, andimprovement. In the spirit of showing rather
than telling, publishing the roadmap andthe details behind these phases will build
confidence that the products are secureby design. After achieving meaningfulprogress, manufacturers can detail themin transparency reports. Doing so not only
demonstrates a commitment to secure by
design principles but can inspire others
to adopt similar programs by showing an
existence proof.

3. Publish a memory-safety roadmap.
Manufacturers can take steps to eliminate
one of the largest classes of vulnerability
by migrating existing products andbuilding new products using memory safe
languages. While this may not be possible
in all cases, manufacturers can consider
developing application wrappers in memory
safe languages instead of re-writing entire
applications. This can also include how
manufacturers are updating hiring, training,code review, and other internal processes,
as well as ways they are helping the open
source community do the same.
4. Publish results. While updating their
SDLC to embody a secure by design
philosophy, organizations will find quick
wins, more resource intensive wins, andsome unexpected setbacks. By presenting
their internal successes and roadblocks, theentire industry can learn from the results.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

25

TLP:CLEARTLP:CLEART

PRINCIPLE 3: Lead from the Top
EXPLANATION
While the overall philosophy is called “secure by design,” the incentives
for customer safety begin well before the product design phase. They
begin with business goals and implicit and explicit objectives and desired
outcomes. Only when senior leaders make security a business priority,
creating internal incentives, and fostering an across-the-board culture to
make security a design requirement will they achieve the best results.
While technical subject matter expertise is critical to product security, it is
not a matter that can be solely left to technical staff. It is a business prioritythat must start at the top.
Some people have wondered if a software manufacturer is embracing thefirst two principles and producing meaningful artifacts, is the third principle
necessary? How a company establishes its vision, mission, values, andculture will affect the product, and those elements have a heavy component
at the top. We see this in other industries that have made dramatic
improvements in safety and quality. Noted quality expert J.M. Juran wrote:

Attainment of quality leadership requires that theupper managers personally take charge of managing
for quality. In companies that did attain quality
leadership, the upper managers personally guided
the initiative. I am not aware of any exceptions. [3]We believe that security is a sub-category of product quality. Whensecurity and quality become business imperatives rather than technicalfunctions left solely to technical staff, organizations will be able to respondto the security needs of their customers more quickly and efficiently.
Moreover, investing the necessary resources to ensure that software
security is a core business priority from the beginning will reduce the longterm costs of addressing software defects–and in turn, lower the national
security risks.
In the same way that leadership teams have implemented corporate social
responsibility (CSR) programs, there is growing awareness that corporateboards, including those of software manufacturers, should take a more
active role in guiding cybersecurity programs. The term corporate cyber
responsibility (CCR) is sometimes used to describe this emerging idea.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

26

TLP:CLEARTLP:CLEAR
T

DEMONSTRATING THIS PRINCIPLE
To demonstrate this principle, software manufacturers should take steps including thefollowing:
1. Include details of a secure by design
program in corporate financial reports.
If the manufacturer is a publicly traded
company, add a section in each annual
report devoted to secure by design efforts.
It is common for automobile annual financial
reports to include sections on driver andpassenger safety, including information
about centralized and distributed quality
and safety committees. Detailing the secureby design program in a financial report will
demonstrate that the organization is linking
customer security and corporate financial
outcomes and not simply adopting a term inmarketing materials because it is in vogue.

4. Create meaningful internal incentives. While
being mindful to not create perverse incentives,align reward systems to improve customer
security to match other valued behaviors andoutcomes. From the secure by design executive
to product management, software development,
support, sales, legal, and other organizations,
weave customer security incentives into hiring,promotions, salaries, bonuses, stock options, andother common processes in the running of thebusiness. For example, when establishing criteria
for promoting software developers, include
considerations for improving the security of the
product along with other criteria like uptime,
performance, and feature improvements.

2. Provide regular reports to your boardof directors. Chief information security
officer (CISO) reports to corporate boards
usually include information about current
and planned security programs, threats,suspected and confirmed security incidents,and other updates centered on the security
posture and health of the company. In
addition to receiving information about the
security posture of the enterprise, boards
should request information about productsecurity and the impact it has on customer
security. Boards should not look solely to
the CISO, but primarily to other membersof company management to drive customer
risk down.

5. Create a secure by design council. In someindustries, it’s common for organizations to createa central quality council, and to embed quality
representatives in key divisions or business units.
By including both centralized and distributed
members, these groups work to improve quality
against top level goals while receiving telemetry
from deep in the organization. Similarly, asecure by design council would improve security
against secure by design goals throughout theorganization.

3. Empower the secure by design executive.
There is a significant difference between an
organization where the technical teams have“executive buy-in,” and those where businessleaders personally manage the customer
security improvement process using
standard business processes. The term
“executive buy-in” implies that someone had
to sell the idea of a customer safety program
rather than it being a top-level businessgoal. This executive must be empowered toinfluence product investments to achievecustomer security outcomes.

6. Create and evolve customer councils. Manysoftware manufacturers have customer councils
comprised of customers from different regions,industries, and sizes. These councils can provide
a great deal of information about customer
successes and challenges in deploying thecompany’s products. Structure the council agenda
with dedicated topics addressing customer
safety, even if it’s not currently top of mind forthe participants. Consider where the customer
council reports and how to tap participants for
insights into the product’s security as deployed.
For example, does the council have a bias towards
marketing and sales purposes, or productmanagement? The secure by design executive
should help steer these customer interactions andshould link them with other elements in this paper,
such as field studies.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

27

T
TLP:CLEARTLP:CLEARSECURE BY DESIGN TACTICS
The Secure Software Development Framework (SSDF), also known as the National
Institute of Standards and Technology’s (NIST’s) SP 800-218, is a core set of high-levelsecure software development practices that can be integrated into each stage of thesoftware 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.
The authoring organizations encourage the use of secure by design tactics, including
principles that reference SSDF practices. Software manufacturers should develop awritten roadmap to adopt more secure by design software development practices acrosstheir portfolio. The following is a non-exhaustive illustrative list of roadmap best practices:•

Memory safe programming languages (SSDF PW.6.1). Prioritize the use of memory
safe languages wherever possible. The authoring organizations acknowledge
that memory specific mitigations may be helpful shorter-term tactics for legacy
codebases. Examples include C/C++ language improvements, hardware mitigations,address space layout randomization (ASLR), control-flow integrity (CFI), andfuzzing. Nevertheless, there is a growing consensus that adoption of memory
safe programming languages can eliminate this class of defect, and software
manufacturers should explore ways to adopt them. Some examples of modern
memory safe languages include C#, Rust, Ruby, Java, Go, and Swift. Read NSA’s
memory safety information sheet for more.

•

Secure Hardware Foundation. Incorporate architectural features that enablefine- grained memory protection, such as those described by Capability Hardware
Enhanced RISC Instructions (CHERI) that can extend conventional hardware
Instruction-Set Architectures (ISAs), as well as other features like Trusted Platform
Modules and Hardware Security Modules. For more information visit, University ofCambridge’s CHERI webpage.

•

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.

•

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.

•Parameterized queries (SSDF PW 5.1). Use parameterized queries rather thanincluding user input in queries, to avoid SQL injection attacks.

•

Static and dynamic application security testing (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 beincorporated into development processes and run automatically as part of softwaredevelopment. SAST and DAST should complement other types of testing, suchas unit testing and integration testing, to ensure products comply with expected
security requirements. When issues are identified, manufacturers should performroot-cause analysis to systemically address vulnerabilities.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

28

TLP:CLEARTLP:CLEAR•

Code review (SSDF PW.7.1, PW.7.2). Strive to ensure that code submitted into
products goes through quality control techniques such as peer review by otherdevelopers or “error seeding.”•

Software Bill of Materials (SBOM) (SSDF PS.3.2, PW.4.1). Incorporate the creationof SBOM4 to provide visibility into the set of software that goes into products.

•

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 thisdocument (or other similar practices) would have prevented the introduction of thevulnerability.

•

CVE completeness. Ensure that published CVEs include root cause or common
weakness enumeration (CWE) to enable industry-wide analysis of software
security design flaws. While ensuring that every CVE is correct and complete cantake 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 Stakeholder-Specific Vulnerability Categorization (SSVC) guidance.

•

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 Cybersecurity 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 MFA for all
employees— then they cannot be seen as delivering secure by design products.

The authoring organizations recognize that these changes are significant shifts inan organization’s posture. As such, their introduction should be prioritized based on
tailored threat modeling, 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 productmay merit an accelerated schedule to adopt these practices. In others, practices can be
introduced into a legacy codebase and remediated over time.

4

Some of the authoring organizations are exploring alternate approaches to gaining security assurances around the software
supply chain.

CISA | NSA | FBI | ACSC | CCCS | CERT NZ | NCSC-NZ | NCSC-UK | BSI | NCSC-NLN C S C - N O | N Ú K I B | I N C D | K I S A | N I S C - J P | J P C E R T / C C | C S A | C S I R TA M E R I C A S

29

TLP:CLEARTLP:CLEARSECURE BY DEFAULT TACTICS
In addition to adopting secure by design development practices, the authoringorganizations recommend software manufacturers prioritize secure by default
configurations in their products. These should strive to update products to conform tothese practices as they are refreshed. For example:• Eliminate default passwords. Products should not come with default passwords thatare universally shared. To eliminate default passwords, the authoring organizations
recommend products require administrators to set a strong password during
installation and configuration or for the product to ship with a unique, strong password
for each device.
• Mandate multifactor authentication (MFA) for privileged users. We observe thatmany 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.
• Single sign-on (SSO). IT applications should implement single sign on support 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.
• Secure Logging. Provide high-quality audit logs to customers at no extra charge or
additional configuration. Audit logs are crucial for detecting and escalating potential
security incidents. They are also crucial during an investigation of a suspected orconfirmed 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.
• 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 certain information thatis 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”
that are included with 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 organizations&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

30

TLP:CLEARTLP:CLEAR

recognize that shortened hardening guides result from ongoing partnership withexisting customers and include efforts by many product teams, including user
experience (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 mostsecure setting should be integrated into the product by default. When configuration isnecessary, the default option should be broadly secure against common threats.
The authoring organizations acknowledge these changes may have operational effects
on how the software is employed. Thus, customer input is critical in balancing operationaland security considerations. We believe that developing written roadmaps and executive
support that prioritize these ideas into an organization’s most critical products is the firststep to shifting towards secure software development practices. While customer input
is important, we have observed important cases where customers have been unwillingor unable to adopt improved standards, often network protocols. It is important for the
manufacturers to create meaningful incentives for customers to stay current and notallow them to remain vulnerable indefinitely.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

31

TLP:CLEARTLP:CLEAR

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. These guides should be written by security practitioners who can explain the
tradeoffs in clear language to increase the chances of them being applied correctly.
Rather than developing hardening guides that list methods for securing products,
the authoring organizations recommend software manufacturers shift to a secure by
default approach and providing "loosening guides." These guides explain the businessrisk of decisions in plain, understandable language, and can raise organizationalawareness of risks to malicious cyber intrusions. Security tradeoffs should bedetermined by the customers’ senior executives, balancing security with otherbusiness requirements.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

32

TLP:CLEARTLP:CLEAR

RECOMMENDATIONSFOR CUSTOMERSThe authoring organizations recommend organizations holdtheir supplying software manufacturers accountable for the
security outcomes of their products. As part of this, the authoringorganizations recommend that executives prioritize the importanceof purchasing secure by design and secure by default products.
This can manifest through establishing policies requiring that IT
departments assess the security of software before it is purchased,
as well as empowering IT departments to push back if necessary. IT
departments should be empowered to develop purchasing criteriathat 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 businessexecutive, and regularly presented to the board of directors.
Key enterprise IT services that support the organization’s security
posture, such as the enterprise network, enterprise identity andaccess 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 thesecapabilities to leverage manufacturers that embrace secure by
design and secure by default practices.
Where possible, organizations should strive to forge strategic
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 andsecure by default practices in both the formal (e.g., contracts orvendor agreements) and informal dimensions of the relationship.
Organizations should expect transparency from their technology
suppliers about their internal control posture as well as theirroadmap towards adopting secure by design and secure by default
practices.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

33

TLP:CLEARTLP:CLEAR

In addition to making secure by default a priority within an organization, IT leaders
should collaborate with their industry peers to understand which products andservices 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 tomanufacturers and create incentives for them to prioritize security.
When leveraging cloud systems, organizations should ensure they understand theshared responsibility model with their technology supplier. That is, organizations
should have clarity on the supplier's security responsibilities rather than just thecustomer’s responsibilities.
Organizations should prioritize cloud providers that are transparent about theirsecurity posture, internal controls, and ability to live up to their obligations under
the shared responsibility model.

DISCLAIMER
The information in this report is being provided “as is” for informational purposes only.
CISA and the authoring organizations do not endorse any commercial product or service,including any subjects of analysis. Any reference to speciﬁc commercial entities orcommercial products, processes, or services by service mark, trademark, manufacturer,
or otherwise does not constitute or imply endorsement, recommendation, or favoritism by
CISA and the authoring organizations. This document is a joint initiative by CISA that does
not automatically serve as a regulatory document.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

34

TLP:CLEARTLP:CLEARCISA»

CISA’s SBOM Guidance»

CISA’s Cross-Sector Cybersecurity Performance Goals»

Guidelines on Technology Interoperability»

CISA and NIST’s Defending Against Software Supply Chain Attacks»

The Cost of Unsafe Technology and What We Can Do About It | CISA»

Stop Passing the Buck on Cybersecurity: Why Companies Must Build
Safety Into Tech Products (foreignaﬀairs.com)»

CISA’s Stakeholder-Speciﬁc Vulnerability Categorization (SSVC) Guidance»

CISA’s Phishing Resistant MFA Fact Sheets»

Cyber Guidance for Small Businesses | CISA

NSA»

NSA’s Cybersecurity Information Sheet on Memory Safety»

NSA’s ESF Securing the Software Supply Chain: Best Practices for
SuppliersFBI»

Understanding and Responding to the SolarWinds Supply Chain Attack:
The Federal Perspective»

The Cyber Threat - Response and Reporting»

FBI’s Cyber Strategy

National Institute of Standards and Technology (NIST)»

NIST’s Digital Identity Guidelines»

NIST’s Cyber Security Framework»

NIST’s Secure Software Development Framework (SSDF)

Australian Cyber Security Centre (ACSC)

Resources»

ACSC’s IoT Code of Practice Guidance for Manufacturers

The United Kingdom’s National Cyber Security Centre (UK)»The UK’s Cyber Assessment Framework»

The UK NCSC’s Secure Development and Deployment guidance»

The UK NCSC’s Vulnerability Management guidance»

The UK NCSC’s Vulnerability Disclosure Toolkit»

University of Cambridge’s CHERI»

So long and thanks for all the bits - NCSC.GOV.UK

Canadian Centre for Cyber Security (CCCS)»

CCCS’s Guidance on Protecting Against Software Supply Chain Attacks»

Cyber supply chain: An approach to assessing risks»

Canadian Centre for Cyber Security’s CONTI ransomware guidance&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

35

TLP:CLEARTLP:CLEAR

Germany’s Federal Office for Information Security (BSI)»The BSI Grundschutz compendium (module CON.8)»

The international standard IEC 62443, part 4-1»

State of IT-security in Germany report, 2022»

BSI practices of web application security

Netherland’s National Cyber Security Centre»

NCSC-NL’s Mature Authentication Factsheet

Japan’s National Center of Incident Readiness and Strategy
for Cybersecurity (NISC)»

Japan’s National Cybersecurity Strategy

Japan’s Ministry of Economy, Trade and Industry (METI)»

Guide of Introduction of Software Bill of Materials (SBOM) for Software
Management»

Collection of Use Case Examples Regarding Management Methods for
Utilizing OSS and Ensuring Its Security

Cyber Security Agency of Singapore»

Technical Advisory on Secure API Development»

CSA SingCERT Vulnerability Disclosure Policy»

CSA SingCERT Incident Response Checklist»

CSA SingCERT Incident Response Playbooks»

CSA Security by Design Framework»

CSA Security by Design Framework Checklist»

CSA Guide to Cyber Threat Modelling»

CSA Cybersecurity Labelling Scheme

Other
»

How Complex Systems Fail»

The New Look in complex system failure

REFERENCES[1] https://csrc.nist.rip/publications/history/ande72.pdf[2] https://www.cisa.gov/sbom and SBOMs references in TR 03183-2 https://www.bsi.bund.de/dok/TR-03183[3] Juran on Quality by Design by J.M. Juran, 1992.

&,6$_16$_)%,_$&6&_&&&6_&(571=_1&6&1=_1&6&8._%6,_1&6&1/
1 & 6 &  1 2  _  1 Ó . , %  _  , 1 & '  _  . , 6 $  _  1 , 6 &  - 3  _  - 3 & ( 5 7  & &  _  & 6 $  _  & 6 , 5 7$ 0 ( 5 , & $ 6

36

TLP:CLEAR