Five Eyes、ドイツ、オランダ、ノルウェー、韓国、イスラエル、日本、シンガポール、チェコ他 セキュア・バイ・デザイン原則の改訂
こんにちは、丸山満彦です。
米国は、
- CISA
- 連邦捜査局（FBI）
- 国家安全保障局（NSA）
それ以外の国は、
- オーストラリア・サイバーセキュリティセンター（ACSC）
- カナダ・サイバーセキュリティセンター（CCCS）
- カナダ・サイバーセキュリティセンター（CCCS）
- 英国国家サイバーセキュリティセンター（NCSC-UK）
- ドイツ連邦情報セキュリティ局（BSI）
- オランダ国立サイバーセキュリティセンター（NCSC-NL）
- ノルウェー国家サイバーセキュリティセンター（NCSC-NO）
- コンピューター緊急対応チームニュージーランド（CERT NZ）・ニュージーランド国家サイバーセキュリティセンター（NCSC-NZ）
- 韓国インターネット振興院（KISA）
- イスラエル国家サイバー総局（INCD）
- サイバーセキュリティセンター（NISC）・JPCERTコーディネーションセンター（JPCERT/CC）
- OAS/CICTE 政府サイバーインシデント対応チーム（CSIRT）アメリカネットワーク
- シンガポールサイバーセキュリティ庁（CSA）
- チェコ共和国国家サイバー情報セキュリティ庁（NÚKIB）
が2023.04.13に公表したセキュア・バイ・デザイン原則を改訂し文書を公表していますね。。。強制力のない、ガイドラインです。
前回は、日本がはいっていませんでしたが、今回はNISCとJPCERT/CCが入っていますね。。。
ちなみにデジタル庁は、
・2022.06.30 [PDF] 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン
を公表しています。こちらも強制力のないガイドラインです。。。
セキュリティをシートベルトに例えるのはセキュリティ・バイ・デザインの文脈で説明する際には、わかりやすいかもですね。。。
・シートベルトはオプションではない
・シートベルトは利用者が使いやすいように設計されている
● CISA
・2023.10.16 Secure-by-Design
・[PDF]
仮対訳...
blog
・2023.10.17 The Next Chapter of Secure by Design
| The Next Chapter of Secure by Design | セキュア・バイ・デザインの次の章 |
| Yesterday, CISA Director Jen Easterly announced the second iteration of CISA’s Secure by Design whitepaper, “Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software” at the Singapore Cyber Week conference. Since releasing the first version of the whitepaper in April, we received a great deal of constructive and detailed feedback from a wide spectrum of stakeholders, including software manufacturers of all sizes, customers, non-profits, academics, U.S. and international government agencies, and individuals. Ten U.S. and international partners co-sealed the first version of the whitepaper. This version includes an incredible eight additional countries and international organizations. This scale of feedback and partnership underscores that the industry is keen to have this conversation, and that the time to shift the responsibility for security is now. We have been honored by how generous people have been with their time and expertise. | 昨日、CISAのディレクターであるジェン・イースタリー（Jen Easterly）氏は、シンガポール・サイバー・ウィーク（Singapore Cyber Week）会議において、CISAのホワイトペーパー「セキュア・バイ・デザイン（Secure by Design）」の第2版「サイバーセキュリティ・リスクのバランスの転換：セキュア・バイ・デザイン・ソフトウェアの原則とアプローチ（Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software）」を発表した。4月にホワイトペーパーの初版を発表して以来、あらゆる規模のソフトウェアメーカー、顧客、非営利団体、学術関係者、米国および国際的な政府機関、個人など、幅広いステークホルダーから建設的で詳細なフィードバックを数多くいただいた。ホワイトペーパーの最初のバージョンは、米国内外のパートナー10社によって共同承認された。今回のバージョンには、さらに8カ国と国際機関が含まれている。このような大規模なフィードバックとパートナーシップは、業界がこのような対話を熱望していること、そしてセキュリティの責任を転換する時が今であることを強調している。私たちは、人々が時間と専門知識を惜しみなく提供してくれたことを光栄に思っている。 |
| The feedback spanned all sections of the document, including commentary on which software development practices were most helpful in the design and development of secure software. One of the most common themes was centered on the three Secure by Design principles. That is gratifying because the principles were the heart of the document, despite that section not being very long. People were picking up what we were laying down. | 安全なソフトウエアの設計と開発において、どのソフトウエア開発プラクティスが最も役に立つかについてのコメントも含め、フィードバックは文書のすべてのセクションに及んだ。最も一般的なテーマのひとつは、セキュア・バイ・デザインの3原則を中心としたものであった。そのセクションはそれほど長くないにもかかわらず、原則がこの文書の中心であったため、これは喜ばしいことである。人々は、私たちが敷設したものを受け止めてくれたのだ。 |
| In addition to listening to the community’s feedback, we held a few initial secure by design summits. The first summit was an internal CISA summit geared towards educating the CISA workforce we called “Summit Zero” where we spent an entire day hosting both internal and external speakers to explain the many challenges facing the software industry as it seeks to build more secure products. Speakers covered topics ranging from OT security, to economic challenges, to the history of the “quality by design” movement in manufacturing. | コミュニティからのフィードバックに耳を傾けることに加え、私たちはセキュア・バイ・デザイン・サミットを数回開催した。最初のサミットは、「サミット・ゼロ」と呼んでいるCISA従業員の教育を目的とした社内のCISAサミットで、丸一日かけて社内外のスピーカーを招き、より安全な製品の構築を目指すソフトウェア業界が直面する多くの課題について説明した。講演者は、OTセキュリティから経済的課題、製造業における「クオリティ・バイ・デザイン」運動の歴史に至るまで、さまざまなトピックを取り上げた。 |
| We’ve since held two other summits. The first focused on the K-12 education technology (or “EdTech”) market. A number of EdTech companies, ranging from small to large, participated to share their experiences in serving their customers while trying to improve their secure development practices. This goal is a significant challenge for smaller software companies, and one the industry needs to address: How can we democratize the “well-lit paths” that some larger software companies have created to ensure the path of least resistance for their software developers is also the most secure one? | その後、サミットは2回開催された。最初のサミットは、K-12教育テクノロジー（EdTech）市場に焦点を当てたものだった。小規模なものから大規模なものまで、多くのEdTech企業が参加し、セキュアな開発手法の改善を図りながら顧客にサービスを提供してきた経験を共有した。この目標は、中小ソフトウェア企業にとって重要な課題であり、業界が取り組むべき課題でもある： ソフトウェア開発者にとって最も抵抗の少ない道が、最も安全な道でもあることを確実にするために、一部の大手ソフトウェア会社が作り上げた「明るい道」をどのように民主化できるだろうか？ |
| Following the summit, we launched a pledge with top K-12 software manufacturers focused on secure by design practices. The pledge lays out specific actions that EdTech companies are committing to take, including not charging extra for basic security features and publishing a secure by design roadmap. In the coming months, we’re planning on expanding this pledge out to other sectors. In the meantime, K-12 software manufacturers can reach out if interested in joining the pledge. | サミットの後、私たちは、セキュア・バイ・デザインの実践に焦点を当てた、K-12のトップ・ソフトウェア・メーカーとの誓約書を発表した。この誓約には、基本的なセキュリティ機能に追加料金を課さないこと、セキュア・バイ・デザインのロードマップを公開することなど、EdTech企業が取るべき具体的な行動が記されている。今後数ヶ月のうちに、この誓約を他の分野にも拡大する予定である。それまでの間、幼稚園から高校までのソフトウェア・メーカーは、この誓約に参加することに興味があれば、連絡を取ることができる。 |
| The second summit focused on university and community college computer science programs. At this event we heard about the challenges facing faculty who are trying to satisfy many goals as they prepare the nation’s software workforce for their careers. Topics ranged from teaching memory safe programming languages, to defensive programming practices, to the incentives that guide universities and their faculty’s programs. | 2回目のサミットは、大学およびコミュニティ・カレッジのコンピューター・サイエンス・プログラムに焦点を当てたものであった。このイベントでは、国内のソフトウェア労働者のキャリアを準備する中で、多くの目標を満たそうとする教授陣が直面する課題について聞いた。トピックは、メモリ安全プログラミング言語の教育から、防御的プログラミングの実践、大学とその教員のプログラムを導くインセンティブまで多岐にわたった。 |
| Since April, we’ve worked to incorporate feedback into a new version of the whitepaper. As noted above, we heard from numerous software industry stakeholders, large and small, governmental and private, suppliers and customers. We’ve briefed numerous nonprofit and industry organizations. We attended workshops to learn about company software development processes. We attended the DEF CON conference in Las Vegas in August and held a “red pen” session where we invited DEF CON participants to literally mark up the draft whitepaper with a red pen. Much red ink was spilled that day, my friends. | 4月以来、我々はフィードバックをホワイトペーパーの新バージョンに反映させるべく努力してきた。前述したように、大小、政府、民間、サプライヤー、顧客など、数多くのソフトウェア業界の関係者から意見を聞いた。非営利団体や業界団体にも数多く説明した。企業のソフトウェア開発プロセスについて学ぶワークショップに参加した。8月にはラスベガスで開催されたDEF CONカンファレンスに参加し、DEF CONの参加者に文字通り赤ペンでホワイトペーパーの草稿に印を付けてもらう「赤ペン」セッションを行った。その日、多くの赤ペンがこぼれた。 |
| Based on the prevailing feedback that people wanted more information about the three principles, we expanded that section substantially in two ways. First, we provided more context to help readers understand the intent behind each principle. Second, we introduced the concept of evidence in the form of artifacts. We wanted to know what artifacts a software manufacturer could present to demonstrate that they are investing in a secure by design program. The idea is that no one artifact would convince an outsider, but a collection of artifacts might start to tell a compelling story. | 人々が3つの原則についてより多くの情報を求めているという一般的なフィードバックに基づき、我々は2つの方法でそのセクションを大幅に拡張した。第一に、各原則の背後にある意図を読者が理解できるよう、より多くの文脈を提供した。第二に、成果物という形の証拠の概念を導入した。私たちは、ソフトウェアメーカーがセキュア・バイ・デザイン・プログラムに投資していることを証明するために、どのような成果物を提示できるかを知りたかった。一つの成果物だけでは部外者を納得させることはできないが、成果物の集まりが説得力のあるストーリーを語り始めるかもしれない、という考え方である。 |
| Software companies have asked how they can get more involved. The best way is to demonstrate the three principles. Look at the list of suggested artifacts in the new whitepaper and make public the ones you are currently doing. We need companies that are already engaging in these behaviors to teach others what “good” looks like. If you are a customer, start to ask potential vendors for some of the artifacts listed in the whitepaper. We need buyers to create a significant demand signal that will nudge incentives towards secure by design engineering. | ソフトウェア会社からは、どうすればもっと関与できるかという質問があった。最善の方法は、3つの原則を示すことである。新しいホワイトペーパーで提案されている成果物のリストを見て、現在行っているものを公表してほしい。私たちは、「良い」とはどのようなものかを他の人々に教えるために、すでにこれらの行動に取り組んでいる企業を必要としている。もしあなたが顧客なら、ホワイトペーパーに掲載されている成果物のいくつかを、ベンダー候補に求め始めよう。バイヤーには、デザイン・エンジニアリングによるセキュア化へのインセンティブを後押しするような、大きな需要シグナルを生み出してもらう必要がある。 |
| In the coming weeks, we’ll be releasing a Request for Information (RFI) on secure by design engineering. We’re especially interested on any feedback on areas our whitepaper can be improved and what areas CISA should focus its future efforts on. | 今後数週間のうちに、セキュア・バイ・デザイン・エンジニアリングに関する情報提供要請書（RFI）を発表する予定である。特に、我々のホワイトペーパーを改善できる分野や、CISAが今後力を入れるべき分野についてのフィードバックに関心がある。 |
| We heard many ideas that we continue to contemplate, and much like software development, we will work to address them in future versions of the whitepaper. In the meantime, we look forward to reading more about the ways in which companies adopt a secure by design philosophy for their products and their customers. | ソフトウェア開発と同様、私たちはホワイトペーパーの将来のバージョンでそれらに取り組むつもりである。それまでの間、セキュア・バイ・デザインの哲学を自社製品や顧客のために採用する企業の方法について、さらに読むことを楽しみにしている。 |
● NISC
・2023.10.17 国際共同ガイダンス「Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security by Design and Default」に署名しました
・[PDF] 報道発表資料
・[HTML] 英文
・[PDF] 仮訳
● まる・ちゃんの情報セキュリティ気まぐれ日記
米国等によるセキュリティ・バイ・デザイン
・2023.08.14 米国 K-12（幼稚園から高校まで）の学校のサイバーセキュリティを強化する新たな取り組みを開始 (2023.08.07)
・2023.04.25 Five Eyesの国々が安全なスマートシティを作るための共同ガイダンスを発表 (2023.04.20)
・2023.04.15 CISA他 サイバーセキュリティリスクのバランスを変える：セキュリティ・バイ・デザインとセキュリティ・バイ・デフォルトの原則とアプローチ
日本政府のセキュリティ・バイ・デザイン
・2022.07.02 デジタル庁 デジタル社会推進標準ガイドラインにセキュリティに関するドキュメントが追加されましたね。。。
仮対訳はこんな感じ???
customerは顧客ではなく「利用者」、makerはメーカーではなく「製造者」ってしてます。。。
| SHIFTING THE BALANCE OF CYBERSECURITY RISK: | サイバーセキュリティリスクのバランスを変える： |
| PRINCIPLES AND APPROACHES FOR SECURE BY DESIGN SOFTWARE | セキュア・バイ・デザイン・ソフトウェアの原則とアプローチ |
| Contents | 目次 |
| OVERVIEW: VULNERABLE BY DESIGN | 概要：デザインによる脆弱性 |
| WHAT’S NEW | 最新情報 |
| HOW TO USE THIS DOCUMENT | この文書の使い方 |
| SECURE BY DESIGN TACTICS | セキュア・バイ・デザインの戦術 |
| Secure by Default | セキュア・バイ・デフォルト |
| RECOMMENDATIONS FOR SOFTWARE MANUFACTURERS | ソフトウェア製造者への推奨事項 |
| SOFTWARE PRODUCT SECURITY PRINCIPLES | ソフトウェア製品のセキュリティ原則 |
| PRINCIPLE 1: Take Ownership of Customer Security Outcomes | 原則 1： 利用者のセキュリティ成果を所有する |
| EXPLANATION | 説明 |
| DEMONSTRATING THIS PRINCIPLE | この原則を実証する |
| PRINCIPLE 2 : Embrace Radical Transparency and Accountability | 原則2：抜本的な透明性と説明責任を受け入れる |
| EXPLANATION | 説明 |
| DEMONSTRATING THIS PRINCIPLE | この原則を示す |
| PRINCIPLE 3: Lead from the Top | 原則3：トップが率先垂範する |
| EXPLANATION | 説明 |
| DEMONSTRATING THIS PRINCIPLE | この原則を示す |
| SECURE BY DESIGN TACTICS | セキュア・バイ・デザインの戦術 |
| SECURE BY DEFAULT TACTICS | デフォルトで安全な戦術 |
| HARDENING VS LOOSENING GUIDES | ガイドを固めるか緩めるか |
| RECOMMENDATIONS FOR CUSTOMERS | 利用者への提言 |
| DISCLAIMER | 免責事項 |
| OVERVIEW: VULNERABLE BY DESIGN | 概要：デザインによる脆弱性 |
| Technology 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 to potential safety1 risks. | テクノロジーは日常生活のほぼあらゆる面に組み込まれており、インターネットに接続されたシステムは、個人のID管理から医療に至るまで、私たちの経済的繁栄や生活、さらには健康にまで直接影響を及ぼす重要なシステムに、ますます私たちをつないでいる。このような便利さの欠点の一例として、世界的なサイバー侵害があり、その結果、病院は手術をキャンセルし、患者の治療を迂回させている。重要なシステムにおける安全でない技術や脆弱性は、悪意のあるサイバー侵入を招き、潜在的な安全1リスクにつながる可能性がある。 |
| 1 The authoring organizations recognize that the term “safety” has multiple meanings depending on the context. For the purposes of this guide, “safety” will refer to raising technology security standards to protect customers from malicious cyber activity. | 1 「安全」という用語は、文脈によって複数の意味を持つことを、本作成組織は認識している。本ガイドの目的上、「安全性」とは、悪意のあるサイバー活動から利用者を保護するための技術セキュリティ基準を引き上げることを指す。 |
| As a result, it is crucial for software manufacturers to make secure by design and secure by default the focal points of product design and development processes. Some vendors have made great strides driving the industry forward in software assurance, while others 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 are encouraged to take ownership of improving the security outcomes of their customers. Historically, software manufacturers have relied on fixing vulnerabilities found after the customers have deployed the products, requiring the customers to apply those patches at their own expense. Only by incorporating secure by design practices will we break the vicious cycle of 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 critical prerequisite to features and speed to market. Over time, engineering teams will be able to establish a new steady-state rhythm where security is truly designed-in and takes less effort to maintain. | この高水準のソフトウエア・セキュリティを達成するために、オーサリング団体 は、機能および市場投入スピードの重要な前提条件として、製品セキュリティの統合を優 先することをメーカーに奨励している。時が経てば、エンジニアリング・チームは、セキュリティが真にデザイン・インされ、維持にかかる労力が少なくなるような、新たな定常状態のリズムを確立できるようになるだろう。 |
| Reflecting this perspective, the European Union reinforces the importance of product security in the Cyber Resilience Act, emphasizing that manufacturers should implement security throughout a product‘s life-cycle in order to prevent manufacturers from introducing vulnerable products into the market. | このような視点を反映して、欧州連合（EU）は、サイバー・レジリエンス法の中で、製品セキュリティの重要性を強化しており、メーカーが脆弱な製品を市場に投入することを防ぐために、製品のライフサイクル全体を通じてセキュリティを実装すべきであると強調している。 |
| 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. Well before development, products that are secure by design are conceptualized with the security 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 can evolve 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, these two philosophies move much of the burden of staying secure to manufacturers and reduce the chances that customers will fall victim to security incidents resulting from misconfigurations, insufficiently fast customer patching, or many other common issues. | 技術や関連製品が利用者にとってより安全な未来を創造するため、本作成組織はメーカーに対し、設計と開発プログラムを見直し、設計とデフォルトで安全な製品の出荷のみを許可するよう促す。セキュア・バイ・デザインの製品は、開発のはるか以前から、単なる技術的な特徴ではなく、利用者の安全をビジネスの中核的な目標として構想されている。セキュア・バイ・デザインの製品は、開発を開始する前にその目標から出発する。既存の製品は、複数回の反復を経て、セキュア・バイ・デザインの状態へと進化させることができる。セキュア・バイ・デフォルト（Secure by default）製品とは、設定をほとんど変更することなく、「箱から出してすぐに」安全に使用できる製品であり、追加コストなしにセキュリティ機能を利用できる製品である。この2つの哲学を組み合わせることで、セキュアな状態を維持する重荷の多くをメーカーに移し、設定ミスや利用者によるパッチ適用が不十分であったり、その他多くの一般的な問題に起因するセキュリティ・インシデントの犠牲となる可能性を減らすことができる。 |
| 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 to ensure security of their products: | Cybersecurity and Infrastructure Security Agency（CISA）、National Security Agency（NSA）、Federal Bureau of Investigation（FBI）、および以下の国際パートナー2 は、ソフトウェアメーカーが自社製品のセキュリティを確保するためのロードマップとして、本ガイドの推奨事項を提供している： |
| 2 Hereafter referred to as the “authoring organizations.” | 2 以下、"本作成組織"と呼ぶ。 |
| » Australian Cyber Security Centre (ACSC) | ・ オーストラリア・サイバーセキュリティセンター（ACSC |
| » Canadian Centre for Cyber Security (CCCS) | ・ カナダ・サイバーセキュリティセンター（CCCS） |
| » United Kingdom’s National Cyber Security Centre (NCSC-UK) | ・ 英国国家サイバーセキュリティセンター（NCSC-UK） |
| » Germany’s Federal Office for Information Security (BSI) | ・ ドイツ連邦情報セキュリティ局（BSI） |
| » Netherlands’ National Cyber Security Centre (NCSC-NL) | ・ オランダ国立サイバーセキュリティセンター（NCSC-NL） |
| » Norway’s National Cyber Security Center (NCSC-NO) | ・ ノルウェー国家サイバーセキュリティセンター（NCSC-NO） |
| » Computer Emergency Response Team New Zealand (CERT NZ) and New Zealand’s National Cyber Security Centre (NCSC-NZ) | ・ コンピューター緊急対応チームニュージーランド（CERT NZ）とニュージーランド国家サイバーセキュリティセンター（NCSC-NZ） |
| » Korea Internet & Security Agency (KISA) | ・ 韓国インターネット振興院（KISA） |
| » Israel’s National Cyber Directorate (INCD) | ・ イスラエル国家サイバー総局（INCD） |
| » Japan’s National Center of Incident Readiness and Strategy for Cybersecurity (NISC) and Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) | ・ サイバーセキュリティセンター（NISC）とJPCERTコーディネーションセンター（JPCERT/CC） |
| » OAS/CICTE Network of Government Cyber Incident Response Teams (CSIRT) Americas | ・ OAS/CICTE 政府サイバーインシデント対応チーム（CSIRT）南北アメリカネットワーク |
| » Cyber Security Agency of Singapore (CSA) | ・ シンガポールサイバーセキュリティ庁（CSA） |
| » Czech Republic’s National Cyber and Information Security Agency (NÚKIB) | ・ チェコ共和国国家サイバー情報セキュリティ庁（NÚKIB） |
| The authoring organizations recognize the contributions by many private sector partners in advancing security by design and security by default. This product is intended to progress an international conversation about key priorities, investments, and decisions necessary to achieve a future where technology is safe, secure, and resilient by design and default. To that end, the authoring organizations seek feedback on this product from interested parties and intend to convene a series of listening sessions to further refine, specify, and advance our guidance to achieve our shared goals. | 本作成組織は、設計によるセキュリティとデフォルトによるセキュリティの推進に多くの民間セクターのパートナーが貢献していることを認識している。本文書は、設計とデフォルトにより、技術が安全、セキュア、かつ、レジリエントである未来を実現するために必要な、主要な優先事項、投資、意思決定に関する国際的な対話を進展させることを意図している。そのため、本作成組織は、関係者からの本文書に関するフィードバックを求め、また、共通の目標を達成するためのガイダンスをさらに洗練し、特定し、前進させるために、一連のリスニング・セッションを開催する予定である。 |
| For more information on the importance of product safety, see CISA’s article, The Cost of Unsafe Technology and What We Can Do About It. | 製品安全の重要性についての詳細は、CISAの記事「The Cost of Unsafe Technology and What We Can Do About It」を参照のこと。 |
| WHAT’S NEW | 最新情報 |
| 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, and trade associations. The most common request in the feedback was to provide more detail on 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. | 2023年4月の発表後、本作成組織（以後「我々」「我々の」と呼ぶ）は、何百もの個人、企業、業界団体から心のこもったフィードバックを受け取った。フィードバックの中で最も多かった要望は、ソフトウェア・メーカーとその利用者の双方に適用される3つの原則について、より詳しく説明してほしいというものだった。本書では、当初の報告書を発展させ、メーカーや利用者の規模、利用者の成熟度、原則の適用範囲といった他のテーマについても触れる。 |
| 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 and maintenance, 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 the practices described in this paper led to particular security improvements. | ソフトウェアはあらゆるところに存在し、単一の報告書で、ソフトウェアシステム、ソフトウェア製品の開発、利用者への展開と保守、他のシステムとの統合の全範囲を適切にカバーすることはできない。以下のガイダンスのうち、特定の環境に明確にマッピングされていないものについては、本稿に記載されている実践方法が特定のセキュリティ改善にどのようにつながったかをコミュニティから聞くことを楽しみにしている。 |
| This report applies to manufacturers of artificial intelligence (AI) software systems and models 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. | 本報告書は、人工知能（AI）ソフトウェア・システムやモデルの製造業者にも適用される。従来の形態のソフトウェアとは異なるかもしれないが、基本的なセキュリティ対策はAIシステムやモデルにも適用できる。セキュア・バイ・デザインの実践の中には、AI特有の考慮事項を考慮するために修正が必要なものもあるかもしれないが、セキュア・バイ・デザインの3つの包括的な原則は、すべてのAIシステムに適用される。 |
| We recognize that transforming a software development lifecycle (SDLC) to align with these 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 believe that the software industry needs to make widely available the tools and procedures that make 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. | これらのセキュア・バイ・デザインの原則に沿うように、ソフトウェア開発ライフサイクル（SDLC）を変革することは、単純な作業ではなく、時間がかかるかもしれないことを、私たちは認識している。さらに、小規模なソフトウェアメーカは、これらの提案の多くを実施するのに苦労するかもしれない。私たちは、ソフトウェア業界が、製品をより安全にするツールと手順を広く利用できるようにする必要があると信じている。より多くの人々や組織がソフトウェア・セキュリティの改善に注目するようになれば、すべての利用者の利益となるような、大規模なソフトウェア・メーカーと小規模なソフトウェア・メーカーとの間のギャップを縮めるような技術革新の余地があると信じている。 |
| 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 with success. | このセキュア・バイ・デザイン・レポートの更新は、技術的エコシステムを支える多くのステークホルダー・コミュニティとパートナーシップを築くという我々のコミットメントの一環である。この報告書は、そのエコシステムの多くの部分からのフィードバックの結果であり、私たちは引き続き、様々な視点からの意見に耳を傾け、学んでいく。この先には多くの課題が待ち受けているが、すでにセキュア・バイ・デザインの理念を採用し、しばしば成功を収めている人々や組織について学ぶにつれ、私たちは信じられないほど楽観的になっている。 |
| HOW TO USE THIS DOCUMENT | この文書の使い方 |
| We urge software manufacturers to adhere to the principles within this document. 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 of these principles and to create artifacts that will build a compelling case to even skeptical current and potential customers that they are embodying the secure by design philosophy. | 私たちは、ソフトウェアメーカーがこの文書にある原則を遵守することを強く求める。ソフトウェアメーカーは、以下に列挙するステップに沿って、自分たちのとった行動を公に文書化することで、そのコミットメントを示すことができる。我々は、ソフトウェア製造者が、これらの原則の精神に合致する戦術を見つけ、セキュア・バイ・デザインの理念を体現していることを、懐疑的な現在の利用者や潜在的な利用者にさえ説得力のあるケースを構築する成果物を作成することを奨励する。 |
| In addition to actions software manufacturers should take, customers can also leverage this document. Companies buying software should ask hard questions of their vendors, drawing inspiration from the examples of adhering to the principles listed in this document. In doing so, customers can help to shift the market towards products that are more secure by design. An example of questions customers can ask of vendors is given in CISA’s Guidance for K-12 Technology Acquisitions. | ソフトウェアメーカーが取るべき行動に加え、利用者もこの文書を活用することができる。ソフトウェアを購入する企業は、この文書に記載されている原則を遵守している事例からヒントを得ながら、ベンダーに厳しい質問を投げかけるべきである。そうすることで、利用者は、設計上より安全な製品へと市場をシフトさせることができる。利用者がベンダーに尋ねることができる質問の例は、CISA の「K-12 技術獲得のためのガイダンス」に示されている。 |
| We encourage enterprise customers to incorporate these practices into procurement processes, vendor due diligence assessments, enterprise risk 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 to take steps towards greater security. In other words, just as we seek to create a pervasive secure by design philosophy within software manufacturers, we need to create a “secure by demand” culture with their customers. | 企業の利用者には、調達プロセス、ベンダーのデューデリジェンス評価、企業のリスク受容の決定、およびベンダーを評価する際のその他のステップに、これらの慣行を組み込むことを奨励する。また、利用者は、各ベンダーがセキュア・バイ・デザイン（Secure by Design）を実践していることを文書化するよう、ベンダーに働きかけるべきである。このようなことを積み重ねることで、セキュリ ティに対する強い要求シグナルを生み出し、ソフトウェアメーカーがよりセキュリ ティを高めるための措置を講じることを奨励し、可能にすることができる。言い換えれば、ソフトウエアメーカーにセキュア・バイ・デザインの哲学を浸透させるのと同様に、ソフトウエアメーカーの利用者とともに「セキュアバイデマンド」の文化を創造する必要がある。 |
| Secure by Design | セキュア・バイ・デザイン |
| “Secure by design” means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure. Software manufacturers should perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape. | 「セキュア・バイ・デザイン」とは、悪意のあるサイバー行為者がデバイス、データ、接続されたインフラへのアクセスを成功させることから合理的に保護する方法で、テクノロジー製品が構築されていることを意味する。ソフトウェア・メーカーは、重要システムに対する一般的なサイバー脅威を特定・列挙するためのリスク評価を実施し、進化するサイバー脅威の状況を考慮した保護策を製品の設計図に含めるべきである。 |
| Secure information technology (IT) development practices and multiple layers of defense— known as defense-in-depth—are also recommended to prevent 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 product development stage to address all potential threats to a system and account for each system’s deployment process. | また、悪意のある行為者がシステムを侵害したり、機密データに不正アクセスしたりするのを防ぐため、安全な情報技術（IT）開発の実践と、Defense-in-Depthとして知られる多重防御も推奨される。さらに、システムに対する潜在的なすべての脅威に対処し、各システムの展開プロセスを考慮するため、製品開発段階でメーカーに合わせた脅威モデルを使用することを推奨している。 |
| The authoring 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 business priority, not just a technical feature. This collaboration between business leaders and technical teams extends from the preliminary stages of design and 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 to programming languages that eliminate widespread vulnerabilities). They should prioritize the features, mechanisms, and implementation of tools that protect customers rather than product features that seem appealing but enlarge the attack surface. | 各本作成組織は、メーカーに対し、製品やプラットフォームに対して全体的なセキュリティ・アプローチをとるよう促す。セキュア・バイ・デザインの開発には、製品の設計・開発プロセスの各層で、ソフトウエアメーカーが専用リソースを戦略的に投資することが必要である。そのためには、セキュリティ を単なる技術的な機能としてではなく、ビジネス上の優先事項として位置づけるような、メー カーの経営トップによる強力なリーダーシップが必要である。このようなビジネスリーダーと技術チームのコラボレーションは、設計・開発の前段階から、利用者への配備、保守に至るまで続く。メーカーには、利用者には「見えない」もの（例えば、広範な脆弱性を排除するプログラ ミング言語への移行）も含め、厳しいトレードオフと投資を行うことが奨励される。魅力的に見えるが攻撃対象領域を拡大するような製品機能よりも、利用者を保護する機能、メカニズム、ツールの実装を優先すべきである。 |
| There is no single solution to end the persistent threat of malicious cyber actors exploiting technology vulnerabilities, and products that are “secure by design” will continue to suffer vulnerabilities; however, a large set of vulnerabilities are due to a relatively small subset of root causes. Manufacturers should develop written roadmaps to align their existing product portfolios with more secure by design practices, ensuring to only deviate in exceptional situations. | 技術の脆弱性を悪用する悪意のあるサイバー行為者の永続的な脅威をなくす唯一の解決策はなく、「設計上安全」な製品も脆弱性に悩まされ続ける。しかし、多くの脆弱性は、比較的少数の根本的な原因によるものである。製造者は、既存の製品ポートフォリオをよりセキュアな設計手法に合わせるためのロードマップを文書化し、例外的な状況においてのみ逸脱することを保証すべきである。 |
| The authoring 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 secure by design practices while developing innovative technology products and maintaining existing ones can substantially improve the security posture of customers and reduce the likelihood of compromise. Secure by design principles not only strengthen the security posture for customers and brand reputation for developers but the practice also lowers maintenance and 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. | 以下の「ソフトウェア製造業者への推奨事項」では、製造業者が考慮すべき製品開発の慣行と方針のリストを提供している。 |
| Secure by Default | セキュア・バイ・デフォルト |
| “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. Secure by default products are designed to make customers acutely aware that when they deviate from safe defaults, they are increasing the likelihood of compromise unless they implement additional compensatory controls. Secure by default is a form of secure by design. | 「セキュア・バイ・デフォルト」とは、製品に追加料金を支払うことなく、すぐに一般的な悪用手法に耐性を持たせることを意味する。このような製品は、エンドユーザがセキュリティを確保するための追加措置を講じることなく、最も一般的な脅威や脆弱性から保護される。セキュア・バイ・デフォルトの製品は、安全なデフォルトから外れるとき、追加的な代償制御を実装しない限り、侵害の可能性を高めていることを利用者に痛感させるように設計されている。セキュア・バイ・デフォルトは、セキュア・バイ・デザインの一形態である。 |
| » A secure configuration should be the default baseline. Secure by default products automatically enable the most important security controls needed to protect enterprises from malicious cyber actors, as well as supply the ability to use and further configure security controls at no additional cost. | » セキュアな設定は、デフォルトのベースラインであるべきだ。セキュア・バイ・デフォルトの製品は、悪意のあるサイバー行為者から企業を保護するために必要な最も重要なセキュリティ制御を自動的に有効にし、追加コストなしでセキュリティ制御を使用し、さらに構成する機能を提供する。 |
| » The complexity of security configuration should not be a customer problem. Organizational IT staff are frequently overloaded with security and operational responsibilities, thus resulting in limited time to understand and implement the security implications and mitigations required for a robust cybersecurity posture. Manufacturers can aid their customers by optimizing secure product configuration—securing the “default path”— ensuring their products are manufactured, distributed, and used securely in accordance with “secure by default” standards. | » セキュリティ構成の複雑さは、利用者の問題であってはならない。組織の IT スタッフは、セキュリティと運用の責任で過負荷になっていることが多く、その結果、堅牢なサイバーセキュリティ態勢に必要なセキュリティの意味合いと緩和策を理解し、実装する時間が限られている。製造業者は、セキュアな製品構成を最適化することで、利用者を支援することができる。「デフォルト・パス」をセキュアにすることで、製品が「セキュア・バイ・デフォルト」基準に従って安全に製造、流通、使用されるようにすることができる。 |
| Manufacturers of products that are “secure by default” do not charge extra for implementing 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, but should 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 authoring organizations recommend software manufacturers implement the strategies outlined in the sections below to take ownership of the security outcomes of their customers through secure by design and default principles. | この共同ガイドは、IT セキュリティを実装し確保するためのロードマップを文書化し、製造業者に推奨するものである。本作成組織は、セキュア・バイ・デザイン及びデフォルトの原則を通じて、利用者のセキュリティ成果に主体性を持つために、ソフトウェア製造業者が以下のセクションで概説する戦略を実施することを推奨する。 |
| SOFTWARE PRODUCT SECURITY PRINCIPLES | ソフトウェア製品のセキュリティ原則 |
| 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, configuration, and shipment of their products. | ソフトウェア・メーカーは、ソフトウェア・セキュリティを優先する戦略的焦点を採用することが推奨される。本作成組織は、ソフトウエア製造者が製品の開発、構成、出荷に先立ち、ソフトウエアセ キュリティを設計プロセスに組み込む際の指針として、以下の 3 つの基本原則を策定した。 |
| 1. Take ownership of customer security outcomes and evolve products accordingly. The burden of security should not fall solely on the customer. | 1. 利用者のセキュリティ上の成果を所有し、それに応じて製品を進化させる。セキュリティの負担を利用者だけに負わせてはならない。 |
| 2. 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 they learn from their customer deployments, such as the uptake of strong authentication mechanisms by default. It also includes a strong commitment to ensure vulnerability advisories and associated common vulnerability and exposure (CVE) records are complete and accurate. However, 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. | 2. 抜本的な透明性と説明責任を受け入れる。ソフトウエアメーカーは、安全でセキュアな製品を提供することに誇りを持つととも に、その能力に基づいて他のメーカーコミュニティとの差別化を図るべきである。これには、デフォルトでの強力な認証メカニズムの導入など、利用者の導入から学んだ情報を共有することも含まれる。また、脆弱性アドバイザリおよび関連する共通脆弱性公表（CVE）記録が完全かつ正確であることを保証するための強力なコミットメントも含まれる。ただし、CVEをネガティブな指標としてカウントする誘惑には注意すること。このような数値は、健全なコード分析・テストコミュニティの証でもあるからだ。 |
| 3. Build organizational structure and leadership to achieve these goals. While technical subject matter expertise is critical to product security, senior executives are the primary decision makers for implementing change in an organization. Executives need to prioritize security as a critical element of product development across the organization, and in partnership with customers. | 3. これらの目標を達成するための組織構造とリーダーシップを構築する。製品セキュリティにとって技術的な専門知識は不可欠であるが、上級幹部は、 組織に変革を導入するための主要な意思決定者である。経営幹部は、組織全体にわたって、また、利用者とのパートナーシップの下で、製品開発の重要な要素としてセキュリティを優先する必要がある。 |
| To enable these three principles, manufacturers should consider several operational tactics to evolve their development processes. | これら 3 つの原則を実現するために、メーカーは、開発プロセスを進化させるためのいくつかの運用戦術を検討する必要がある。 |
| Convene routine meetings with company executive leadership to drive the importance of secure by design and secure by default within the organization. Policies and procedures should be established to reward production teams that develop products adhering to these principles, which could include awards for implementing outstanding software security practices or incentives for job ladders and promotion criteria. | 会社の経営幹部との定期的なミーティングを開催し、セキュアバイデザ インとセキュア・バイ・デフォルトの重要性を組織内に浸透させる。これらの原則に従った製品を開発した製造チームに報いるための方針と 手順を確立する。この方針と手順には、優れたソフトウエアセキュリ ティ対策の実施に対する表彰や、職階や昇進基準に対するインセンティブを含めることができる。 |
| Operate around the importance of software security to business success. For example, consider assigning a “software security leader” or a “software security team” that upholds business and IT practices 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. | 事業の成功に対するソフトウエアセキュリティの重要性を中心に据えた運営を行う。例えば、「ソフトウエアセキュリティリーダー」や「ソフトウエアセキュリティチーム」を任命し、ソフトウエアセキュリティ標準とメーカーの説明責任を直結させるビジネ スと IT の慣行を維持することを検討する。製造事業者は、自社製品について強固で独立した製品セキュリティ評価・ 評価プログラムを確実に実施する。 |
| 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 specific use-case and enable development teams to fortify products. Finally, senior leadership should hold teams accountable for delivering secure products as a key element of product excellence and quality. | リソースの割当てと開発時に、カスタマイズした脅威モデルを使用して、最 も重要で影響の大きい機能に優先順位を付ける。脅威モデルは、製品固有のユースケースを考慮し、開発チームが製品を強化できるようにする。最後に、シニアリーダーは、製品の卓越性と品質の重要な要素として、安全な製品を提供する責任をチームに課すべきである。 |
| As part of the October 2023 update to this guidance, these three principles are expanded upon through the following explanations, demonstrations, and evidence. | 本ガイダンスの2023年10月の更新の一環として、これらの3つの原則は、以下の説明、実証、及び証拠を通じて拡大される。 |
| PRINCIPLE 1: Take Ownership of Customer Security Outcomes | 原則 1： 利用者のセキュリティ成果のオーナーシップを持つ |
| EXPLANATION | 説明 |
| Modern best practices dictate that software manufacturers invest in product security efforts that include application hardening, application features, and application default settings. | 最新のベストプラクティスでは、ソフトウエア製造者は、アプリケーションのハーデニング、アプリケーション機能、アプリケーションのデフォルト設定を含む製品セキュリティの取り組みに投資することが指示されている。 |
| Software manufacturers need to implement application hardening by using processes and technologies that raise the cost for a malicious actor wishing to compromise applications. Application hardening protocols and procedures help products resist attacks by intelligent malicious actors. Terms like hardening, product security, 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 software development life cycle (SDLC) management, and using hardware-backed cryptographic key management. | ソフトウエアメーカは、アプリケーションを侵害しようとする悪意ある行為者のコストを高めるプロセスと技術を使用して、アプリケーショ ン・ハーデニングを実施する必要がある。アプリケーションハーデニングのプロトコルと手順は、インテリジェントな悪意ある行為者による攻撃に製品が抵抗するのを助ける。ハーデニング、製品セキュリティ、レジリエンスといった用語は、すべて製品品質と密接に関連している。この考え方は、セキュリティは "組み込み"でなければならず、"後付け"であってはならない、というものである。[1] セキュリティを組み込むことによって、ソフトウェアメーカーは、利用者のセキュリティを高めるだけでなく、製品の品質も高めることができる。戦術の例としては、ユーザ入力を確実に検証し、サニタイズし、コードに直接入力しない（すなわち、代わりにパラメータ化されたクエリを使用する）、メモリ安全なプログラミング言語を使用する、厳密なソフトウェア開発ライフサイクル（SDLC）管理を行う、ハードウェアに裏付けされた暗号鍵管理を使用する、などがある。 |
| Applications need to support application features that relate to cybersecurity. Sometimes called “capabilities,” these features extend the functionality of a product or service in ways that help maintain or increase the security posture of a customer. | アプリケーションは、サイバーセキュリティに関連するアプリケーション機能をサポートする必要がある。機能」と呼ばれることもあるこれらの機能は、利用者のセキュリティ態勢の維持や向上に役立つ方法で、製品やサービスの機能を拡張する。 |
| 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 attribute-based access control (ABAC). | セキュリティ関連の機能の例としては、すべてのネットワーク接続に対するトランスポート・レイヤー・セキュリティ（TLS）のサポート、シングルサインオン（SSO）のサポート、多要素認証（MFA）のサポート、セキュリティイベントの監査ロギング、役割ベースのアクセス制御（RBAC）、属性ベースのアクセス制御（ABAC）などがある。 |
| Some of these product features are configurable allowing customers to more easily 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 more secure. | これらの製品機能の一部は設定可能であるため、利用者は製品を既存の環境やワークフローにより簡単に統合することができる。これらのコンフィギュレーションは、利用者がコンフィギュレーションするまで、アプリケーションにデフォルト設定が設定されていなければならないことを意味する。これらのデフォルト設定は、利用者がテクノロジー製品のスタックをよりセキュアにするために費やすリソースが少なくなるように、「箱から出してすぐに」セキュアに設定される必要がある。 |
| Each of these elements – application hardening, application security features, and application default settings – plays a role in the security of the application, and the resulting 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 their products. Manufacturers should take it a step further and consider how those elements change 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 should be 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 cause of that defect. The product might implement different mitigations in various parts of the code 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 across the entire application. | 残念ながら、現在はそうなっていない。あまりにも多くのメーカーが、包括的なアプリケーションのハーデニングに投資するのではなく、利用者にセキュリティの負担を押し付けている。例えば、メーカーがある脆弱性にパッチを適用した場合、その欠陥の根本原因ではなく対症療法に対処したため、同様の脆弱性が露呈することがよくある。その製品は、同じクラスの脆弱性に対して、コードベースのさまざまな部分で異なる緩和策を実装しているかもしれない。その一例として、メーカーがある入力サニタイズの脆弱性を修正した後、研究者や攻撃者が、改善された入力サニタイズの恩恵を受けないコードパスを発見した。製造者は、アプリケーション全体にわたってそのクラスの脆弱性を排除するためにコードベースを統一するのではなく、一度に一つずつ修正を適用した。 |
| Application features can create both benefits and risk for customers. Features that allow 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 the implications 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 upgrade and deploy modern security measures. They may use products that integrate with the rest of the organization’s network, but lack modern security measures, preventing the IT team from modernizing. Still, software manufacturers can factor these patterns into their planning process to encourage customers to stay current. | アプリケーションの機能は、利用者に利益とリスクの両方をもたらす可能性がある。多くの外部システムやバージョンとの統合ポイントを可能にする機能は、製品の価値を大きく高めることができる。しかし、ネットワーキング・プロトコルのように、引退プランのない機能をサポートすることは、利用者がその機能を継続的に使用することの意味を理解していない場合、脆弱性を残す可能性がある。例えば、1990年代や2000年代に起源を持ち、現在では安全でないことが知られているネットワーキング・プロトコルを使い続けている製品もある。利用者が最新のセキュリティ対策をアップグレードし、導入するスピードを遅らせる要因は数多くある。組織の他のネットワークと統合する製品を使用していても、最新のセキュリティ対策が欠けているため、ITチームが最新化を進めることができない場合もある。それでも、ソフトウェア・メーカーは、こうしたパターンを計画プロセスに組み込むことで、利用者に最新の状態を維持するよう促すことができる。 |
| 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 that are 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 be on by default or which settings are needed to be secure by default. Another tactic is to investigate ways to make features more discoverable for the administrator. | アプリケーションのデフォルト設定は、利用者にとって潜在的なリスクである。メーカーはしばしば特定のデフォルト設定を選択し、利用者が望むアプリケーション機能を使いやすくしている。しかし、このやり方は、デフォルトで有効になっている特定の機能やプロトコルを必要としない利用者にとって、攻撃対象が増えるという欠点がある。さらに、多くのセキュリティ制御は、デフォルトでオフに設定されているか、セキュリティを向上させるために時間をかけて設定を行う必要がある。明示的な脅威モデリングは、どの機能をデフォルトでオンにするか、またはどの設定をデフォルトでセキュアにする必要があるかを決定する際に役立つ戦術である。もう一つの戦術は、管理者が機能をより発見しやすくする方法を検討することである。 |
| Some manufacturers ship products with defaults that can create risk for some or all their customers. Rather than set safer defaults, they often opt to produce a hardening guide that 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 to properly implement hardening guide instructions, especially if the instructions do not make the 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 resource• constrained environments. Relying on hardening guides simply doesn’t scale. | メーカーによっては、一部またはすべての利用者にリスクを生じさせる可能性のあるデフォルト設定で製品を出荷している。より安全なデフォルトを設定する代わりに、ハーデニングガイドを作成し、利用者が自費で実装することを選択することが多い。ハーデニングガイドには、いくつかの共通の問題がある。ハーデニングガイドの中には、見つけるのが難しく、サポートも十分でないものがある。また、実装が複雑で、ソフトウェア開発に拡張モジュールを書かなければならないものもある。さらに、さまざまな設定が攻撃対象領域をどのように変化させるかを理解するために、読者がサイバーセキュリティに関する豊富な経験を持っていることを前提としているものもある。攻撃者の活動方法について不完全に理解している実務者は、特にその指示がトレードオフを明確にしていない場合、ハーデニングガイドの指示を適切に実装できない可能性がある。さらに、すべてのハーデニングガイドが、攻撃者の戦術や経済性に精通したエンジニアによって書かれているわけではないため、忠実に実施したとしても効果のないハーデニングガイドを作成することになる。何百万という利用者が、多くの場合リソースに制約のある環境で、複数のソフトウェアやシステムのインスタンスをハーデニングする責任を負っている。ハーデニングガイドに依存することは、単純にスケールしない。 |
| An application’s settings should be continuously evaluated whether the settings were the default or set by the customer, against the manufacturer’s current understanding of the threat 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 like a modern car has an indicator about seatbelts and expresses that indicator by sounding an 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 and their entire organization are in danger if they do not configure MFA. Additionally, if an application 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. | アプリケーションの設定は、その設定がデフォルトであろうと利用者が設定したものであろうと、脅威の状況に関する製造者の現在の理解に照らして継続的に評価されるべきである。アプリケーションは、それらの設定から生じる可能性のある潜在的なリスクに関する明確な指標とともに作成されるべきであり、それらの指標を周知すべきである。最新の自動車がシートベルトに関する指標を持ち、シートベルトを締めずに運転しようとすると警告音が鳴ることでその指標を表現するように、ソフトウェアはシステムのセキュリティ状態に関する指標を表現すべきである。アプリケーションが管理者アカウントに MFA を要求しないように設定されている場合、MFA を設定しなければ、管理者とその組織全体が危険にさらされることを、管理者に定期的に認識させるべきである。さらに、アプリケーションが、現在では脆弱な暗号を実装することが知られている古いプロトコルをサポートするように設定されている場合、管理者に対して、組織が危険にさらされていることを定期的に明らかにし、状況を解決するためのリソースを提供すべきである。私たちは、ハーデニングガイドを解釈する時間、専門知識、意識を管理者に依存するのではなく、製品に組み込まれた日常的なナッジを実装するようメーカーに強く求める。セキュリティとユーザビリティのバランスを考慮した技術革新の機会は、明らかに存在する。 |
| Each of the above elements creates an untenable situation in which customers need to 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, and time which taxes bandwidth and function, forcing security to a lower priority, and, in the aggregate, exacerbates collective risk. Conversely, security investments by the relative few manufacturers will scale. A common phrase that summarizes the problem is that the software industry needs more secure products, not more security products. Software manufacturers should lead that transformation. | 上記の各要素は、侵害の可能性を減らすために、利用者が追加のセキュリティ製品を調査し、資金を調達し、購入し、人員を配置し、配備し、監視する必要があるという、どうしようもない状況を生み出している。中小規模の組織（SMO）は一般に、こうした選択肢を促進することができない。専門知識、資金、時間の不足に直面し、帯域幅と機能に負荷をかけ、セキュリティの優先順位を下げざるを得ず、全体として集団リスクを悪化させる。逆に、相対的に少数のメーカーによるセキュリティ投資は、規模を拡大する。この問題を要約する常套句は、ソフトウェア業界が必要としているのは、よりセキュアな製品であって、より多くのセキュリティ製品ではないというものだ。ソフトウェアメーカーは、その変革をリードすべきである。 |
| The software industry needs more secure products, not more security products. Software manufacturers should lead that transformation. | ソフトウェア業界が必要としているのは、よりセキュアな製品であって、より多くのセキュリティ製品ではない。ソフトウェア・メーカーはその変革をリードすべきである。 |
| Today, we sometimes read comments from manufacturers explaining that a customer was compromised due to not enabling a particular security feature or following specific hardening guidance. Instead, after a compromise, manufacturers should explain whether a particular security feature or specific hardening guidance would have prevented the compromise and consider making it the default at no charge. In those cases where the product itself was not sufficiently hardened in the design and implementation phases, the manufacturer 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 and effectiveness 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 the academic and security research community could use to track high-level trends and measure progress ecosystem wide. | ソフトウェア・メーカーは、自社の製品がセキュリティを最優先して設計・開発されていることを保証する責任がある。そのためには、現場での努力の成果を客観的に測定すべきである。私たちは、メーカに対して、社内の取り組みだけに注目するのではなく、製品のセキュリティの取り組みと設定の結果と有効性を客観的に測定し、定期的に報告すること、そして、利用者の安全性とより安全な製品の測定可能な改善につながる SDLC の変化を生み出すフィードバックループを構築することを呼びかける。報告には、学術とセキュリティの研究コミュニティがハイレベルな傾向を追跡し、エコシステム全体の進捗を測定するために使用できる匿名化されたデータを含めるべきである。 |
| 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 is implementing 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. This approach is in the spirit of “show, rather than tell.” | ソフトウェア・メーカーやオンライン・サービスは、この原則を実行することで成功したことを示す方法を見つけるべきである。部外者が調査できるように、成果物という形で証拠を提供するよう努めるべきである。単一の成果物だけでは、その製造者が堅牢なセキュア・バイ・デザイン・プ ログラムを実装していることを証明することはできないが、さまざまな成果物を提供する ことで、その製造者がセキュアな製品を開発することにコミットしていることを証明するこ とができる。このアプローチは、"語るより、むしろ示す "という精神に基づくものである。C188 |
| To demonstrate this principle, software manufacturers should consider steps such as 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. | この原則を示すために、ソフトウエアメーカーは以下のリストのようなステップを検討すべきである。本作成組織は、セキュア・バイ・デザインの旅の開始時に、これらの実践を直ちに実施し、対応する成果物を作成できるソフトウエア製造者はほとんどいないことを認識している。さらに、ソフトウエア製造者は、利用者が現場で製品をどのように展開するかによって、このリストに優先順位をつけ、最大のセキュリティ上の利点を達成する必要がある。 |
| 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 this chronic problem will deny easy access to attackers. Similarly, manufacturers should consider what password practices should be implemented, such as minimum password length and disallowing known breached passwords. | 1. デフォルト・パスワードをなくす。デフォルト・パスワードは、毎年多くの攻撃の原因として指摘され続けている。この慢性的な問題をなくすことを約束することで、攻撃者が簡単にアクセスできなくなる。同様に、メーカーは、パスワードの長さを最低限にしたり、既知の漏洩パスワードを認めないなど、どのようなパスワード対策を実施すべきかを検討すべきである。 |
| 2. Conduct field tests. As technology continues to evolve and become more complex, it is increasingly important for software manufacturers to conduct security-centric user testing to understand their products’ security posture in the field. Similar to how user research informs software development requirements, software manufacturers should also conduct security-focused user research to understand where the security 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 can help identify areas for improvement and refine 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. | 2. フィールドテストを実施する。技術が進化を続け、複雑化するにつれて、ソフトウエア・メーカーがセキュリティ中心のユーザー・テストを実施し、現場における自社製品のセキュリティ態勢を理解することがますます重要になっている。ユーザ調査からソフトウエア開発要件が得られるのと同様に、ソフトウエアメーカは、セキュリ ティに焦点を当てたユーザ調査を実施して、セキュリティ・ユーザ・エクスペリエンス（UX） の不足点を把握する必要がある。利用者が実際の環境で自社製品をどのように導入し、使用しているかを観察することによって、ソフトウエアメーカーは、自社のセキュリティ機能や制御の使いやすさと有効性についての貴重な洞察を得ることができる。これらの洞察は、改善すべき領域を特定し、利用者のセキュリティ・ニーズをよりよく満たすように製品を改良するのに役立つ。例えば、フィールドテストは、UXフロー、デフォルト、アラート、モニタリングの変更を示唆するかもしれない。また、フィールドテストによって、製品設計における過去の改善点が、セキュリ ティパッチの適用速度を低減し、設定エラーを低減し、攻撃対象領域を最小化する場 所を示すかもしれない。 |
| Manufacturers should consider the following: | 製造者は、次のことを考慮すべきである： |
| • Do customers correctly implement the hardening 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 likelihood of compromise? | • どの機能がより侵害の可能性を低減できるか？ |
| Note: To gain deeper insights into these elements, software manufacturers may wish to partner with customers to conduct red team exercises to see how the product resists attacks. These field tests might take place at the customer’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 postures by streamlining or even eliminating product hardening guides and focusing on the most critical security measures that customers should prioritize when deploying their products. Rather than overwhelming customers with a laundry list of security measures, manufacturers should identify the top security risks that their products are susceptible to and provide clear and concise guidance on how to mitigate these risks. 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 in their environment. These tools should additionally be able to verify and clearly show the changes made from the original baseline. By streamlining hardening guides and providing customers with easy-to-use tools and automation, manufacturers can reduce the burden on their customers and help ensure that their products are deployed in a secure manner. One tactic would be to consider implementing the Pareto principle to reduce the number of steps for the common use cases (the 80%), and then providing contextual guidance and tooling for less common scenarios (the 20%). In this way, software manufacturers will be making the simple things simple, and the hard things possible. Field testing will be a powerful tool in measuring how long it 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 implement tasks from a hardening guide. | 3. ハーデニングガイドのサイズを小さくする。製造業者は、製品のハーデニングガイドを合理化するか、あるいは廃止し、製品を導入する際に利用者が優先すべき最も重要なセキュリティ対策に焦点を絞ることによって、利用者のセキュリティ体制を改善することができる。メーカーは、セキュリティ対策の羅列で利用者を圧倒するのではなく、自社製品が影響を受けやすい上位のセキュリティリスクを特定し、これらのリスクを軽減する方法について明確かつ簡潔なガイダンスを提供すべきである。さらに、メーカーは、セキュリティ対策の実施プロセスを簡素化するツールや自動化機能（例えば、利用者の環境に簡単に導入できるスクリプトなど）を利用者に提供すべきである。さらに、これらのツールは、元のベースラインからの変更点を検証し、明確に示すことができなければならない。ハーデニングガイドを合理化し、使いやすいツールと自動化を利用者に提供することで、メー カーは利用者の負担を軽減し、製品が安全な方法で配備されることを確実にすることができる。一つの戦術として、パレートの原理を導入して、一般的なユースケース（80％）についてはステップ数を減らし、一般的でないシナリオ（20％）については状況に応じたガイダンスとツールを提供することを検討することが考えられる。こうすることで、ソフトウェアメーカーは単純なことを単純にし、難しいことを可能にする。フィールドテストは、利用者がハーデニングガイドを発見し、理解し、実施するのにかかる時間を測定するための強力なツールとなる。メーカーは、管理者がハーデニングガイドのタスクを実施することに依存するのではなく、製品自体の中で管理者が行動を起こすよう、製品がどのように誘導できるかを検討すべきである。 |
| 4. Actively discourage use of unsafe legacy features.Prioritize security through clear upgrade paths over backwards 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 critical security 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. | 4. 後方互換性よりも、明確なアップグレードパスによるセキュリティを優先する。より安全な機能やプロトコルの採用を示すブログ記事を公開し、安全でない機能については、場合によっては製品内部からのアナウンスによって非推奨とする。かなりの数の利用者が、最新のネットワーク、ID、その他の重要なセキュ リティ機能でシステムを最新に維持しないことを表明している。場合によっては、既存の機能がアップグレードによって壊れることを恐れているケースもある。アップグレードを可能な限りシームレスにすることで、利用者はアップグレードを行い、より頻繁かつ迅速にセキュリティ修正を受けるようになるだろう。ソフトウェア・メーカーは、利用者のリスクを低減するようなアップグレードの道筋を、積極的に後押しすべきである。 |
| 5. Implement attention grabbing alerts. Similar to seat belt chimes in cars that continuously make noise when seat belts are not fastened, manufacturers should implement timely and repeated alerts when users or admins are in truly unsafe states, warning administrators that they are using deprecated protocols in their environments and suggest upgrade paths. Implement timely and repeated alerting when users or admins, or the application configuration, are in an unsafe state. Make the unsafe 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 upon each login, or even disable certain key features until they enable MFA. There is room to innovate to achieve these goals while not creating alert fatigue. | 5. 注意を引くような警告を実施する。自動車のシートベルトチャイムが、シートベルトが締まっていないときに継続的に音を出すのと同様 に、メーカーは、ユーザや管理者が本当に安全でない状態にあるときに、適時に繰り返しアラートを発し、 管理者が自分の環境で非推奨のプロトコルを使用していることを警告し、アップグレードの道筋を提案す るべきである。ユーザーや管理者、あるいはアプリケーションのコンフィグレーションが安全でない状態にあるとき、適時に繰り返し警告を出す。安全でないモードを管理者に定期的に明示する。追加機能として、スーパー管理者がログインのたびにアカウントにMFAがないことを確認するよう求めたり、MFAを有効にするまで特定の主要機能を無効にしたりすることもできる。アラート疲れを起こさないようにしながら、これらの目標を達成するために革新する余地がある。 |
| 6. Create secure configuration templates. These templates can pre-set certain configurations to safe 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 the organization. Templates can be supported by hardening guides on the risks the manufacturer has identified. | 6. セキュアな設定テンプレートを作成する。これらのテンプレートは、組織のリスク選好度に基づいて、特定の設定を安全な設定に事前設定することができる。低セキュリティ、中セキュリティ、高セキュリティのテンプレートを用意するのは単純すぎるかもしれないが、この例は、組織のリスクを管理するために、いかに多くの設定を更新できるかを示している。テンプレートは、製造者が特定したリスクに関するハーデニングガイドでサポートすることができる。 |
| SECURE PRODUCT DEVELOPMENT PRACTICES | 安全な製品開発の実践 |
| 1. Document conformance to a secure SDLC framework. Secure SDLC frameworks provide objectives and examples across people, processes, and technologies. Consider publishing a detailed 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 set of fundamental, sound practices for secure software development .” | 1. 安全な SDLC フレームワークへの適合を文書化する。セキュアな SDLC フレームワークは、人、プロセス、および、技術にわたる目的と例を提供する。どのセキュアな SDLC フレームワークの管理が実施されたかについての詳細な説明を公表し、使用された代替管理について記述することを検討する。米国内では、NIST のセキュアソフトウェア開発フレームワーク（SSDF）の使用を検討してください。チェックリストではないが、SSDF は、「安全なソフトウエア開発のための基本的で健全な実施方法のセットを記述している」。 |
| 2. Document Cybersecurity Performance Goals (CPG) or equivalent conformance. When an organization attests that they conform to the NIST SSDF standard, they are asserting that their SDLC is informed by well-understood best practices. However, it is not sufficient for them to only have a robust SDLC. They also need to protect their own enterprise and development environments from malicious actors who would seek to manipulate the security properties of the product while it is still in development. This is not a theoretical class of attack, but one that has 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 other cybersecurity program frameworks. | 2. サイバーセキュリティ性能目標（CPG）または同等の適合性を文書化する。組織が NIST の SSDF 規格に適合していることを証明するとき、その組織は、その SDLC が十分に理解されたベストプラクティスに基づいていることを主張することになる。しかしながら、堅牢な SDLC を持つだけでは十分ではない。彼らはまた、開発中の製品のセキュリティ特性を操作しようとする悪意のある行為者から、彼ら自身の企業と開発環境を保護する必要があります。これは、理論上の攻撃のクラスではなく、利用者、ひいては国家安全保障に悪影響を及ぼしながら実行されてきたものである。組織は、CISA CPG、NIST サイバーセキュリティフレームワーク（CSF）、またはその他のサイバーセキュリティプログラムフレームワークに対する組織の適合性に関する詳細を公表することを検討すべきである。 |
| 3. Vulnerability management. Some manufacturers have a vulnerability management program that focuses on patching vulnerabilities discovered internally or externally, and little more. More mature programs incorporate extensive data• driven analysis of vulnerabilities and their root causes, taking steps to systemically eliminate entire classes of vulnerability3. They implement formal programs around setting quality planning, quality control, quality improvement, and quality measurement. They view defect management as a business matter, not merely a security matter. These programs are not dissimilar in some ways to quality and safety programs in other industries. | 3. 脆弱性管理。脆弱性管理プログラムは、内部または外部から発見された脆弱性にパッチを適用することに重点を置いており、それ以上のことはほとんど行っていないメーカーもある。より成熟したプログラムでは、脆弱性とその根本原因に関する広範なデータ主導の分析が組み込まれており、脆弱性のクラス全体を体系的に排除するための措置が講じられている3。彼らは、品質計画、品質管理、品質改善、品質測定の設定に関する正式なプログラムを実施している。彼らは、欠陥管理を単なるセキュリティ問題ではなく、ビジネス問題としてとらえている。これらのプログラムは、他産業における品質・安全プログラムと似て非なるものである。 |
| 4. Responsibly use open source software. When open source software is used, be responsible by vetting open source packages, fostering code contributions back to dependencies, and helping sustain the development and maintenance of critical components. For reference, Japan’s Ministry of Economy, Trade, and Industry (METI) has published "Collection of Use Case Examples Regarding Management Methods for Utilizing OSS and Ensuring Its Security ." | 4. オープンソースソフトウェアを責任を持って使用する。オープンソースソフトウェアを使用する場合は、オープンソースパッケージを吟味し、依存関係へのコード寄与を促進し、重要なコンポーネントの開発と保守の持続を支援することにより、責任を持つ。参考までに、日本の経済産業省は、"OSSの活用とセキュリティ確保のための管理手法に関するユースケース事例集 "を公表している。 |
| 5. Provide secure defaults for developers. Make the default route during software development the secure one by providing safe building 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 class of vulnerability. Also known as “paved roads” or “well-lit paths,” this practice ensures both speed and security, and reduces human error. | 5. 開発者に安全なデフォルトを提供する。開発者に安全なビルディングブロックを提供することにより、ソフトウェア開発時のデフォルトルートを安全なものにする。例えば、SQLインジェクションの脆弱性が蔓延し、実世界に被害をもたらしていることを考慮し、開発者がそのクラスの脆弱性を防ぐために、よく整備されたライブラリを使用するようにする。舗装された道」や「よく照らされた道」とも呼ばれるこのやり方は、スピードとセキュリティの両方を保証し、ヒューマンエラーを減らす。 |
| 6. Foster a software developer workforce that understands security. Ensure that your software developers understand security by training them on secure coding best practices. Further, help transform 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 and software development curriculums. | 6. セキュリティを理解するソフトウェア開発者を育成する。セキュアコーディングのベストプラクティスをトレーニングすることによって、ソフトウ ェア開発者がセキュリティを理解するようにする。さらに、セキュリティの知識を評価するように採用方法を更新し、大学、コ ミュニティカレッジ、ブートキャンプ、その他の教育機関と協力して、コンピュータサイエンスとソフトウ ェア開発のカリキュラムにセキュリティを組み込むことにより、より幅広い労働力の変革を支援する。 |
| 7. Test security incident event management (SIEM) and security orchestration, automation, and response (SOAR) integration. In addition to conducting field tests, work jointly with popular 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. | 7. セキュリティインシデント・イベント管理（SIEM）とセキュリティオーケストレーショ ン、自動化、対応（SOAR）の統合をテストする。実地テストを実施するだけでなく、一般的な SIEM 及び SOAR プロバイダと共同で、選り抜きの利用者と連携して、インシデント対応チームがどのようにログを使用してセキュリティインシデントの疑いや実際のインシデントを調査しているかを理解する。インシデントに対応した経験のあるソフトウェア開発者はほとんどいないため、対応担当者が期待するほどには役に立たないログ・エントリを作成する可能性がある。SIEM や SOAR の技術と実際のインシデント対応の専門家の両方と協力することで、開発チームは、正しく完全なストーリーを伝えるログを作成し、インシデント発生時の時間を節約し、不確実性を減らすことができる。 |
| 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 to incorporate these principles in their environments. | 8. ゼロトラストアーキテクチャ（ZTA）に合わせる。製品の導入ガイドを、例えば NIST ZTA モデルや CISA ゼロトラスト成熟度モデルと整合させる。利用者がこれらの原則を自分の環境に取り入れるよう奨励する。 |
| 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 an incident. These tactics may require a thorough review of what security events should be logged to provide cybersecurity state awareness, how a customer may configure logging, for what time period logs are retained, how log integrity and storage are protected, and how logs can be analyzed. In some cases, the review may suggest the need for a refactoring of the application’s log management architecture to help make them actionable and at a cost that works for the manufacturer. Working with incident response (IR) experts can increase the chances that the logs will be useful to investigators in the field. See the section on SIEMs. | 1. 追加料金なしでロギングを提供する。クラウドサービスは、セキュリティ関連のログを追加料金なしで生成・保存することを約束する。オンプレミス製品も同様に、追加料金なしでセキュリティ関連のログを生成する。さらに、多くの利用者はインシデントが発生してからでないとセキュリティイベントの価値を理解しない可能性があるため、製品はデフォルトでログを記録すべきである。このような戦術には、サイバーセキュリティの状態を認識させるためにどのようなセキュリティイベントをログに記録すべきか、利用者はどのようにログを記録するよう設定できるか、ログはどの期間保持されるか、ログの完全性と保存はどのように保護されるか、ログはどのように分析できるか、について徹底的なレビューが必要かもしれない。場合によっては、アプリケーションのログ管理アーキテクチャのリファクタリングが必要であることを示唆することもある。インシデントレスポンス（IR）の専門家と協力することで、ログが現場の調査官に役立つ可能性が高まる。SIEMの項を参照のこと。 |
| 2. Eliminate hidden taxes. Publish a commitment to never charge for security or privacy features or integrations. For example, within the larger scope of identity and 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 of reach for many SMOs, preventing them from achieving a strong security posture. Some services charge more to enable MFA for users. Security should not be priced as a luxury good but considered a customer right. Some manufacturers have argued that few customers request these features, and they cost more to maintain. These arguments ignore the fact that few customers will call to complain or bargain, not all customers actually understand what the benefits of these features 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 to include seatbelts, collapsible steering columns, and airbags that save lives in accidents. | 2. 隠れた税金をなくす。セキュリティやプライバシーの機能や統合に対して、決して課金しないというコミットメントを公表する。例えば、アイデンティティとアクセス管理（IAM）の大きな範囲に、シングルサインオン（SSO）サービスと呼ばれるサービスがある。一部のメーカーは、システムをSSOサービス（IDプロバイダーと呼ばれることもある）に接続するために、より多くの料金を請求する。この「SSO税」は、多くのSMOにとって優れたIDおよびアクセス管理が手の届かないものであり、強力なセキュリティ態勢の実現を妨げていることを意味する。サービスによっては、ユーザーに対してMFAを有効にするためにより多くの料金を請求している。セキュリティは贅沢品として価格設定されるべきではなく、利用者の権利とみなされるべきである。一部のメーカーは、このような機能を要求する利用者はほとんどおらず、維持にコストがかかると主張している。このような主張は、クレームや交渉のために電話をかけてくる利用者はほとんどいないこと、すべての利用者がこれらの機能の利点を実際に理解しているわけではないこと、そしてすべての機能には維持費がかかるという事実を無視している。しかし、可用性やデータの完全性のために追加料金を請求するメーカーはあまり見かけない。シートベルト、折りたたみ式ステアリング・コラム、事故時に人命を救うエアバッグを搭載するためのコストと同じように、これらの重要な属性をサポートするためのコストは、すべての利用者が支払う価格に組み込まれているのである。 |
| 3. Embrace open standards. Implement open standards, especially around common network and identity protocols. Avoid proprietary protocols when open standards are available. | 3. オープンスタンダードを採用する。特に共通のネットワーク・プロトコルやIDプロトコルを中心に、オープン・スタンダードを導入する。オープンスタンダードが利用可能な場合は、プロプライエタリなプロトコルを避ける。 |
| 4. Provide upgrade tooling. Many customers are reluctant to adopt the latest version of the product, including deploying newer and more secure features like secure network connections. Software manufacturers can increase customer adoption of new upgrades by providing tooling to help reduce uncertainty and risk. Offer free licenses for customers to test upgrades and patches in a test environment as a way to motivate customers. | 4. アップグレードツールを提供する。多くの利用者は、セキュアなネットワーク接続のような、より新しくセキュアな機能の導入を含め、製品の最新バージョンを採用することに消極的である。ソフトウェア・メーカーは、不確実性とリスクを軽減するためのツールを提供することで、新しいアップグレードの利用者採用を増やすことができる。利用者のモチベーションを高める方法として、テスト環境でアップグレードやパッチをテストできる無料ライセンスを提供する。 |
| PRINCIPLE 2 : Embrace Radical Transparency and Accountability | 原則2：根本的な透明性と説明責任を受け入れる |
| 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, the overwhelming 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 more mature 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 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, and how those programs hold up in the customer environments against real attackers. The collective industry would benefit from more information sharing on topics such as strategies to measure the cost of security defects and to eliminate classes of vulnerability. 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 a luxury 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. | 透明性 の前に "急進的な "という形容詞を選んだことについての注釈である。今日、ソフトウェア・メーカーが、ソフトウェアをどのように開発し、どのように保守しているか、また、長期にわたるデータを使ってどのようにプログラムを成熟させているかについて、詳細な情報を公表することは珍しいことである。ソフトウエア業界では、ソフトウエアをどのように設計しているのか、ガイドツアーを提供しているメーカーはほとんどない。ソフトウェアメーカが、同業他社がどのように SDLC プログラムを構成しているのか、また、それらのプログラムが実際の攻撃者に対して利用者環境でどのように耐えられるのかを見る機会はほとんどない。業界全体としては、セキュリティの欠陥のコストを測定し、脆弱性のクラスを排除する戦略のようなトピックについて、より多くの情報を共有することは有益であろう。このような一般的な慣行の結果、各ソフトウェアメーカーは、製品のセキュリ ティに対処する方法を自ら学ばなければならなくなった。おそらく、セキュリティ機能にぜいたく税を課さないことで、安全性とセキュリティはプロフィット・センターではなくコスト・センターとなり、企業は協力と透明性によって負担を軽くすることで利益を得るだろう。 |
| We want to focus on the tactics that will materially accelerate the evolution of the software 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 and benefit 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 and tradeoffs 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. | 透明性は、同業者が SDLC を成熟させるのを助ける以上のことができる。見込み客や投資家は、メーカが行った投資とトレードオフについて、また、それらの投資が利用者のために作り上げたセキュリティ体制について、より多くを知ることができる。急進的な透明性を受け入れるメーカーは、利用者が価格や機能だけでなく、セキュリティについても購入の意思決定をするのに役立つ情報を提供する。 |
| 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. | 組織がサプライチェーンと SDLC のセキュリティ確保に懸命に取り組んでいるのと同様に、企業は最近、その構築プロセスを侵害された。急進的な透明性を受け入れることは、攻撃と、その会社が将来の攻撃を防止し検出するために行った改善の公開につながるはずである。そのような形の情報共有は、他の組織が同じ運命に見舞われることなく学習するのに役立つだろう。 |
| DEMONSTRATING THIS PRINCIPLE | この原則を実証する |
| To demonstrate this principle, software manufacturers should take steps including the following: | この原則を実証するために、ソフトウェアメーカーは以下のような措置を講じるべきである： |
| SECURE 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. | 1. セキュリティ関連の統計や傾向を集計して公表する。例えば、利用者や管理者による MFA の採用、安全でないレガシー・プロトコルの使用などである。 |
| 2. Publish patching statistics. Detail what percent of customers are on the latest version of the product, and what you are doing to make updates easier and more reliable. | 2. パッチ適用に関する統計を公表する。製品の最新バージョンを使用している利用者の割合や、アップデートをより簡単で信頼性の高いも のにするために実施していることを詳しく説明する。 |
| 3. Publish data on unused privileges. Publish aggregate information on excessive permissions across your customer base as well as the nudges and other changes to the 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. | 3. 未使用権限に関するデータを公表する。利用者ベースの過剰な権限に関する集計情報、および利用者の攻撃サーフェスを減らすために行っている製品へのナッジやその他の変更を公表する。これらの未使用の権限は、シートベルトのチャイムのように、管理者警告の良い候補となる可能性が高い。 |
| SECURE PRODUCT DEVELOPMENT PRACTICES | セキュアな製品開発の実践 |
| 1. Establish internal security controls. Many companies have seen the benefits of moving their data to cloud providers. Now those cloud providers become the target of attackers. Software as a Service (SaaS) providers should publish statistics of their internal controls. For example, SaaS providers should publish statistics on their internal deployment of phishing-resistant MFA, like Fast Identity Online (FIDO) authentication. Ideally, they should be able to say that no staff member can access customer or other sensitive data without authenticating via phishing-resistant MFA. | 1. 内部セキュリティ管理を確立する。多くの企業が、データをクラウド・プロバイダーに移行することにメリットを感じている。そして今、そのクラウド・プロバイダーが攻撃者の標的となっている。SaaS（Software as a Service）プロバイダーは、内部統制の統計を公表すべきである。例えば、SaaSプロバイダーは、FIDO（Fast Identity Online）認証のようなフィッシングに強いMFAの内部展開に関する統計を公表すべきである。理想的には、どのスタッフもフィッシング耐性のある MFA を介した認証なしに利用者やその他の機密データにアクセスできないと言えるようにすることである。 |
| 2. Publish high-level threat models. Secure by design products start with written 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 cover both the enterprise and development environments, as well as the way the software manufacturers intend for it to be used in customer environments. | 2. ハイレベルの脅威モデルを公表する。セキュア・バイ・デザイン製品は、作成者が何を誰から守ろうとしているかを記述した脅威モデルから始まる。効果的な脅威モデルは、侵入が実際にどのように起こっているかに基づいており、企業環境と開発環境の両方をカバーする必要がある。 |
| 3. Publish detailed secure SDLC self• attestations. Manufacturers following NIST SSDF, or other similar frameworks are actively working towards a mature software development lifecycle. Publishing a self-attestation of which controls the manufacturer has enacted, and for which products, would demonstrate a commitment to adhering to these best practices and provide an increased level of confidence to their customers. Other certification schemes include the Israel Cyber Supply Chain Methodology, for instance. | 3. 詳細な安全な SDLC の自己証明を公表する。NIST の SSDF や他の類似のフレームワークに従っているメーカは、成熟したソフトウェア開発ライフサイクルに向けて積極的に取り組んでいる。製造者が、どの製品について、どのような管理を実施したかについて、自己証明書を公表することは、これらのベストプラクティスを遵守するというコミットメントを示し、利用者に対してより高いレベルの信頼を提供することになる。その他の認証スキームとしては、例えば、イスラエル・サイバー・サプライチェーン・メソドロジー（Israel Cyber Supply Chain Methodology）などがある。 |
| 4. Embrace vulnerability transparency. Publish a commitment that will ensure that 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 the vulnerabilities. The more correct and complete the public CVE database is, the more the industry can track how products are becoming more secure, and which classes of vulnerabilities are most prevalent. 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. 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 and remediation of vulnerabilities in existing code. Manufacturers should publish analysis of past vulnerabilities, including any patterns and measures that were taken to address the entire class of vulnerabilities. For example, if a large percentage of a company’s CVEs were related to cross• site 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 of vulnerability for which mitigations have been understood for decades. | 4. 脆弱性の透明性を受け入れる。特定された製品の脆弱性が、正しく完全なCVEエントリとして公表されることを保証するコミットメントを公表する。これは特に、脆弱性の根本原因を特定する共通弱点列挙欄に当てはまる。公開されるCVEデータベースがより正確で完全であればあるほど、業界は製品がどのように安全性を高めているのか、どのクラスの脆弱性が最も普及しているのかを追跡することができる。しかし、CVEをネガティブな指標としてカウントする誘惑には気をつけよう。このような数字は、健全なコード解析・テストコミュニティの証でもあるからだ。メーカーがセキュア・バイ・デザインの哲学を導入するにつれ、既存のコードにおける脆弱性をより包括的に発見し、是正するため、最初のうちは生のCVE数が増える可能性がある。メーカーは、過去の脆弱性の分析結果を公表すべきであり、その中には、脆弱性のクラス全体に対応するために取られたパターンや対策も含まれる。例えば、ある企業のCVEの大きな割合がクロスサイトスクリプティング（XSS）に関連していた場合、根本原因の分析、対応（XSSを防止するウェブテンプレートフレームワークへの移行など）、結果を文書化することで、数十年前から緩和策が理解されているクラスの脆弱性の被害に遭わないことを利用者に知らせることができる。 |
| 5. Publish Software Bills of Materials (SBOMs). Manufacturers should have command of their supply chains. Organizations should build and maintain SBOMs [2] for each product, request data from their suppliers, and make SBOMs available for downstream customers and users. This will help demonstrate their diligence in understanding the components they use in the creation of their products, their ability to respond to newly identified risks, and can help customers understand how to respond if one of the modules in the supply chain has a newly found vulnerability. 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 and operational capabilities, SBOMs play an important role in the infrastructure to detect and respond to malicious supply chain attacks. | 5. ソフトウェア部品表（SBOM）を公開する。メーカーはサプライチェーンを掌握すべきである。組織は、製品ごとにSBOM [2]を構築・維持し、サプライヤーにデータを要求し、川下の利用者やユーザーがSBOMを利用できるようにすべきである。このことは、製品の製造に使用するコンポーネントを理解するための勤勉さ、新たに特定されたリスクに対応する能力を示すのに役立ち、また、サプライチェーン内のモジュールの1つに新たに脆弱性が見つかった場合に、利用者がどのように対応すべきかを理解するのに役立つ。参考までに、日本の経済産業省（METI）は、"ソフトウェア管理のためのソフトウェア部品表（SBOM） 導入の手引き "を公表している。透明性は、組み込み機器のファームウェアや、AI/機械学習（ML）で使用されるデータやモデルにも及ぶべきである。SBOMは、購買決定や運用能力を支援するだけでなく、悪意のあるサプライチェーン攻撃を検知し対応するためのインフラとして重要な役割を果たす。 |
| 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 with the policy, and (3) allows public disclosure of vulnerabilities after a set timeline. Manufacturers should perform root-cause analysis of discovered vulnerabilities and, to the greatest extent feasible, take actions to eliminate entire vulnerability classes. See CISA’s Vulnerability Disclosure Policy Template for reference language. | 6. 脆弱性開示方針を公表する。(1)メーカーが提供する全製品に対するテストを許可し、それらのテストの条件を定め、(2)ポリシーに合致して実行された行為に対して法的セーフハーバーを提供し、(3)設定されたタイムライン後に脆弱性の公表を許可する脆弱性公表ポリシーを公表する。製造者は、発見された脆弱性の根本原因分析を実施し、可能な限り、脆弱性クラス全体を排除するための措置を講じるべきである。参考文言については、CISAの脆弱性開示ポリシー・テンプレートを参照のこと。 |
| PRO-SECURITY BUSINESS PRACTICES | セキュリティ推進のためのビジネス慣行 |
| 1. Publicly name a secure by design senior executive sponsor. In many organizations, security (like quality) is delegated to technical teams who have limited ability to make structural changes to dramatically improve the security of the products. Publicly naming a top business executive to oversee the secure by design program will transform the security of products into a top-level business concern. | 1. セキュア・バイ・デザインの上級管理職のスポンサーを公的に指名する。多くの組織では、セキュリティは（品質と同様に）技術チームに委ねられており、製品のセ キュリティを劇的に改善するための構造的な変更を行う能力は限られている。セキュアbyデザインプログラムを監督する経営トップの名前を公表することで、製品のセキュリ ティをトップレベルのビジネス上の関心事に変えることができる。 |
| 2. Publish a secure by design roadmap. Manufacturers should document changes made to their SDLC to improve customer security, including details about field• test reports, actions taken to eliminate entire classes of vulnerability, and other items listed in the other principles. As in the case of quality improvement efforts, security improvement programs have distinct phases of planning, control, and improvement. In the spirit of showing rather than telling, publishing the roadmap and the details behind these phases will build confidence that the products are secure by design. After achieving meaningful progress, manufacturers can detail them in 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. | 2. セキュア・バイ・デザインのロードマップを公表する。製造者は、フィールドテストレポートの詳細、脆弱性のクラス全体を排除するために取られた処置、および、他の原則に列挙されたその他の項目を含め、利用者のセキュリティを改善するために SDLC に加えられた変更を文書化するべきである。品質改善の取り組みの場合と同様に、セキュリティ改善プログラムには、計画、管理、改善の明確なフェーズがある。説明するよりも示すという精神に基づき、ロードマップとこれらのフェーズの背後にある詳細を公表することで、製品が設計上安全であるという信頼が構築される。有意義な進捗を達成した後、メーカーは透明性報告書にその詳細を記載することができる。そうすることで、セキュア・バイ・デザインの原則に対するコミットメントを示すだけでなく、存在証明を示すことで、同様のプログラムを採用するよう他者を鼓舞することができる。 |
| 3. Publish a memory-safety roadmap. Manufacturers can take steps to eliminate one of the largest classes of vulnerability by migrating existing products and building 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. | 3. メモリ安全ロードマップを公表する。製造業者は、既存製品の移行やメモリ安全言語を使用した新製品の構築により、最大の脆弱性クラスの一つを排除するための措置を講じることができる。すべてのケースでこれが可能とは限らないが、メーカーは、アプリケーション全体を書き直す代わりに、メモリ安全言語でアプリケーション・ラッパーを開発することを検討することができる。これには、メーカーが採用、トレーニング、コードレビュー、その他の社内プロセスをどのように更新しているか、また、オープンソースコミュニティが同じことを行うのをどのように支援しているかも含めることができる。 |
| 4. Publish results. While updating their SDLC to embody a secure by design philosophy, organizations will find quick wins, more resource intensive wins, and some unexpected setbacks. By presenting their internal successes and roadblocks, the entire industry can learn from the results. | 4. 結果を公表する。セキュア・バイ・デザインの哲学を具現化するために SDLC を更新している間、組織は迅速な成功、より多くのリソースを必要とする成功、そしていくつかの予期しない後退を見つけるだろう。社内の成功と障害を発表することで、業界全体がその結果から学ぶことができる。 |
| PRINCIPLE 3: Lead from the Top | 原則 3：トップがリードする |
| 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 priority that must start at the top. | 製品セキュリティには技術的な専門知識が不可欠であるが、それは技術スタッフだけに任せられる問題ではない。ビジネス上の優先事項であり、トップから着手しなければならない。 |
| Some people have wondered if a software manufacturer is embracing the first two principles and producing meaningful artifacts, is the third principle necessary? How a company establishes its vision, mission, values, and culture 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: | ソフトウェアメーカーが最初の2つの原則を受け入れ、意味のある成果物を生み出しているのであれば、第3の原則は必要なのだろうか、と考える人もいる。企業がどのようにビジョン、ミッション、バリュー、カルチャーを確立するかは製品に影響を与えるものであり、それらの要素はトップに重い要素がある。このことは、安全性と品質を劇的に向上させた他の産業にも見られる。著名な品質専門家J .M. Juranはこう書いている： |
| Attainment of quality leadership requires that the upper 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] | 品質リーダーシップの達成には、上層部が個人的に品質管理を担当することが必要である。品質リーダーシップが達成された企業では、上層部が個人的にイニシアチブを指導していた。私は例外を知らない。[3] |
| We believe that security is a sub-category of product quality. When security and quality become business imperatives rather than technical functions left solely to technical staff, organizations will be able to respond to 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 long-term 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 corporate boards, 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. | リーダーシップ・チームが企業の社会的責任（CSR）プログラムを実施したのと同様に、ソフトウェア・メーカーを含む企業の取締役会は、サイバーセキュリティ・プログラムを指導する上でより積極的な役割を果たすべきであるという認識が高まっている。企業サイバー責任（CCR）という用語は、この新たな考えを表すために使われることもある。 |
| DEMONSTRATING THIS PRINCIPLE | この原則を実証する |
| To demonstrate this principle, software manufacturers should take steps including following: | この原則を実証するために、ソフトウェアメーカーは以下のようなステップを踏むべきである： |
| 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 and passenger safety, including information about centralized and distributed quality and safety committees. Detailing the secure by 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 in marketing materials because it is in vogue. | 1. 企業の財務報告書にセキュア・バイ・デザインプログラムの詳細を記載する。メーカーが株式公開企業である場合は、年次報告書にセキュア・バイ・デザインの取り組みに 関するセクションを設ける。自動車の年次財務報告書には、集中型・分散型の品質・安全委員会に関する情報を含め、運転者・乗客の安全に関するセクションが含まれるのが一般的である。セキュア・バイ・デザイン・プログラムの詳細を財務報告書に記載することで、その組織が利用者のセキュリ ティと企業の財務的成果を結びつけており、単に流行しているからという理由でマーケティング資料で用語を採用し ているのではないことを示すことができる。 |
| 2. Provide regular reports to your board of 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 product security and the impact it has on customer security. Boards should not look solely to the CISO, but primarily to other members of company management to drive customer risk down. | 2. 取締役会に定期的な報告を行う。企業の取締役会に対する最高情報セキュリティ責任者（CISO）の報告には、通常、現在および計画中のセキュリティプログラム、脅威、セキュリティインシデントの疑いや確認など、企業のセキュリティ態勢と健全性を中心とした最新情報が含まれる。取締役会は、企業のセキュリティ態勢に関する情報を受け取ることに加えて、製品のセキュリ ティとそれが利用者のセキュリティに与える影響に関する情報を要求すべきである。取締役会は、CISOだけに期待するのではなく、利用者リスクを低減させるために、主に会社の経営陣の他のメンバーに期待すべきである。 |
| 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 business leaders 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 business goal. This executive must be empowered to influence product investments to achieve customer security outcomes. | 3. セキュア・バイ・デザインの幹部に権限を与える。技術チームが「経営幹部の賛同」を得ている組織と、ビジネスリーダーが標準的なビジネスプロセスを使用して利用者セキュリティ改善プロセスを個人的に管理している組織とでは、大きな違いがある。エグゼクティブの賛同」という用語は、それがトップレベルのビジネス目標であるよりもむしろ、誰かが利用者安全プログラムのアイデアを売り込む必要があったことを意味する。この経営幹部は、利用者セキュリティの成果を達成するための製品投資に影響を及ぼす権限を与えられなければならない。 |
| 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 and outcomes. 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, and other common processes in the running of the business. 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. | 4. 有意義な社内インセンティブを創出する。逆インセンティブを生じさせないように留意しつつ、利用者セキュリティ向上のための報奨制度 を、他の価値ある行動や成果に見合ったものとする。セキュア by デザイン担当役員から、製品管理、ソフトウエア開発、サポート、 営業、法務、その他の組織に至るまで、雇用、昇進、給与、賞与、ストックオプショ ン、その他事業運営における一般的なプロセスに、利用者セキュリティに関するインセン ティブを織り込む。例えば、ソフトウエア開発者の昇進基準を設定するときは、稼働時間、パフ ォーマンス、機能改善などの他の基準とともに、製品のセキュリティ向上も考慮する。 |
| 5. Create a secure by design council. In some industries, it’s common for organizations to create a 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, a secure by design council would improve security against secure by design goals throughout the organization. | 5. セキュア・バイ・デザイン協議会を設置する。業界によっては、中央品質協議会を設置し、主要な部門や事業単位に品質担当者を配置するのが一般的である。集中型と分散型の両方のメンバーを含めることで、これらのグループは、組織の深部からテレメトリを受け取りながら、トップレベルの目標に照らして品質改善に取り組む。同様に、セキュア・バイ・デザイン協議会は、セキュア・バイ・デザインの目標に対するセキュリ ティを組織全体で向上させる。 |
| 6. Create and evolve customer councils. Many software 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 the company’s products. Structure the council agenda with dedicated topics addressing customer safety, even if it’s not currently top of mind for the 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 product management? The secure by design executive should help steer these customer interactions and should link them with other elements in this paper, such as field studies. | 6. 利用者協議会を設立し、発展させる。多くのソフトウエアメーカーは、さまざまな地域、業界、規模の利用者で構成される利用者協議 会を設置している。このような利用者協議会から、自社製品の導入における利用者の成功事例や課題に関する多くの情報を得ることができる。協議会の議題には、利用者の安全性に関する専用のトピックを設定する。カスタマー・カウンシルの報告先と、製品の安全性に関する洞察について、どのように参加者を活用するかを検討する。例えば、利用者協議会はマーケティングや営業目的、あるいは製品管理目的に偏っていないか。セキュア BY デザインのエグゼクティブは、このような利用者との対話の舵取りを支援し、実地調査など本稿の他の要素とリンクさせるべきである。 |
| SECURE 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-level secure software development practices that can be integrated into each stage of the software development lifecycle (SDLC). Following these practices can help software producers become more effective at finding and removing vulnerabilities in released software, mitigate the potential impact of the exploitation of vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences. | セキュアソフトウェア開発フレームワーク（SSDF）は、米国標準技術局（NIST）の SP 800-218 としても知られ、ソフトウェア開発ライフサイクル（SDLC）の各段階に統合することができる、高レベルのセキュアソフトウェア開発プラクティスのコアセットである。これらのプラクティスに従うことで、ソフトウエア開発者は、リリースされたソフトウエアの脆弱性の発見と除去をより効果的に行い、脆弱性の悪用による潜在的な影響を緩和し、将来の再発を防止するために脆弱性の根本原因に対処することができる。 |
| The authoring organizations encourage the use of secure by design tactics, including principles that reference SSDF practices. Software manufacturers should develop a written roadmap to adopt more secure by design software development practices across their portfolio. The following is a non-exhaustive illustrative list of roadmap best practices: | 本作成組織は、SSDF の実践を参照する原則を含め、セキュア・バイ・デザインの戦術の使用を奨励する。ソフトウエア製造者は、よりセキュアな設計によるソフトウエア開発手法を自社のポートフォリオ全体に採用するためのロードマップを文書化すべきである。以下は、ロードマップのベストプラクティスを例示する非網羅的なリストである： |
| • 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), and fuzzing. 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. | • メモリ安全プログラミング言語（SSDF PW.6.1）。可能な限りメモリ安全言語の使用を優先する。レガシーコードベースの短期的な対策として、メモリに特化した緩和策が有用であることを、本作成組織は認めている。例えば、C/C++言語の改良、ハードウェアの緩和、アドレス空間レイアウトのランダム化（ASLR）、制御フロー整合性（CFI）、ファジングなどがある。とはいえ、メモリ安全プログラミング言語を採用することで、この種の不具合をなくすことができるというコンセンサスは高まっており、ソフトウェアメーカーは採用方法を模索すべきである。最新のメモリ安全言語の例としては、C#、Rust、Ruby、Java、Go、Swiftなどがある。詳しくはNSAのメモリ安全性情報シートを参照のこと。 |
| • Secure Hardware Foundation. Incorporate architectural features that enable fine• 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 of Cambridge’s CHERI webpage. | • セキュアなハードウェア基盤。従来のハードウェア命令セット・アーキテクチャ（ISA）を拡張できるCapability Hardware Enhanced RISC Instructions（CHERI）や、Trusted Platform ModulesやHardware Security Modulesなどの機能によって説明されているような、きめ細かなメモリ保護を可能にするアーキテクチャ機能を組み込む。詳細については、ケンブリッジ大学のCHERIウェブページを参照のこと。 |
| • Secure Software Components (SSDF PW 4.1). Acquire and maintain well-secured software components (e .g ., software libraries, modules, middleware, frameworks) from verified commercial, open source, and other third-party developers to ensure robust security in consumer software products. | • 安全なソフトウェアコンポーネント（SSDF PW 4.1）。消費者向けソフトウェア製品の強固なセキュリティを確保するために、検証済みの商用、オープンソース、その他のサードパーティ開発者から、安全性の高いソフトウェア・コンポーネント（ソフトウェア・ライブラリ、モジュール、ミドルウェア、フレームワークなど）を入手し、維持する。 |
| • Web template frameworks (SSDF PW.5.1). Use web template frameworks that implement automatic escaping of user input to avoid web attacks such as cross-site scripting. | • ウェブテンプレートフレームワーク（SSDF PW.5.1）。クロスサイトスクリプティングなどのウェブ攻撃を回避するために、ユーザー入力の自動エスケープを実装したウェブテンプレートフレームワークを使用する。 |
| • Parameterized queries (SSDF PW 5.1). Use parameterized queries rather than including user input in queries, to avoid SQL injection attacks. | • パラメータ化されたクエリ (SSDF PW 5.1)。SQL インジェクション攻撃を回避するために、クエリにユーザ入力を含めるのではなく、パラメータ化されたクエリを使用する。 |
| • Static and dynamic application security testing (SAST/DAST) (SSDF PW .7 .2, PW .8 .2). Use these tools to analyze product source code and application behavior to detect error-prone practices. These tools cover issues ranging from improper management of memory to error prone database query construction (e.g ., unescaped user input leading to SQL injection). SAST and DAST tools can be incorporated into development processes and run automatically as part of software development. SAST and DAST should complement other types of testing, such as unit testing and integration testing, to ensure products comply with expected security requirements. When issues are identified, manufacturers should perform root-cause analysis to systemically address vulnerabilities. | • 静的および動的アプリケーションセキュリティテスト（SAST/DAST）（SSDF PW .7 .2, PW .8 .2）。これらのツールを使用して、製品のソースコードとアプリケーションの動作を分析し、エラーの発生しやす い慣行を検出する。これらのツールは、不適切なメモリ管理から、エラーの発生しやすいデータベースクエリ構築（SQL インジェクションにつながるエスケープされていないユーザ入力など）に至るまで、幅広い問題をカバーしている。SASTおよびDASTツールは、開発プロセスに組み込むことができ、ソフトウェア開発の一部として自動的に実行される。SAST と DAST は、単体テストや統合テストなど他の種類のテストを補完し、製品が期待されるセキュリ ティ要件に適合していることを確認する。問題が特定された場合、製造者は根本原因分析を実施し、脆弱性に体系的に対処する。 |
| • 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 other developers or “error seeding .” | • コードレビュー（SSDF PW .7 .1, PW .7 .2）。製品に提出されたコードが、他の開発者によるピアレビューや "エラーシード "のような品質管理技法を確実に通過するように努める。 |
| • Software Bill of Materials (SBOM) (SSDF PS .3 .2, PW .4 .1). Incorporate the creation of SBOM4 to provide visibility into the set of software that goes into products. | • ソフトウェア部品表（SBOM）（SSDF PS .3 .2, PW .4 .1）。SBOM4 の作成を取り入れ、製品に組み込まれる一連のソフトウェアの可視性を提供する。 |
| • Vulnerability disclosure programs (SSDF RV .1 .3). Establish vulnerability disclosure programs that allow security researchers to report vulnerabilities and receive legal safe harbor in doing so. As part of this, suppliers should establish processes to determine root causes of discovered vulnerabilities. Such processes should include determining whether adopting any of the secure by design practices in this document (or other similar practices) would have prevented the introduction of the vulnerability. | • 脆弱性開示プログラム（SSDF RV .1 .3）。セキュリティ研究者が脆弱性を報告し、その際に法的なセーフハーバーを受けられるような脆弱性開示プログラムを確立する。この一環として、サプライヤは、発見された脆弱性の根本原因を特定するプロセスを確立する。このようなプロセスには、本文書におけるセキュア・バイ・デザインの実践（または他の類似の実践）のいずれかを採用することで、脆弱性の侵入を防ぐことができたかどうかを判断することを含めるべきである。 |
| • CVE completeness. Ensure that published CVEs include root cause or common weakness enumeration (CWE) to enable industry-wide analysis of software security design flaws. While ensuring that every CVE is correct and complete can take extra time, it allows disparate entities to spot industry trends that benefit all manufacturers and customers. For more information on managing vulnerabilities, see CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC) guidance. | • CVE の完全性。公開された CVE には、ソフトウェアセキュリティ設計の欠陥を業界全体で分析できるよう、根本原因または共通弱点列挙（CWE）が含まれるようにする。すべてのCVEが正確かつ完全であることを保証することは、余分な時間を要する可能性がある一方で、すべての製造業者と利用者にとって有益な業界動向を、異質な事業体が発見することを可能にする。脆弱性管理の詳細については、CISAのステークホルダー別脆弱性分類（SSVC）ガイダンスを参照のこと。 |
| • 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. | • サイバーセキュリティ性能目標（CPG）を満たす。基本的なセキュリティ対策を満たす製品を設計する。CISAのCybersecurity Performance Goalsは、組織が実施すべき基本的なサイバーセキュリティ対策の概要を示している。さらに、組織の態勢を強化する方法については、CISAのCPGと共通点を持つ英国のサイバー評価フレームワークを参照されたい。製造者がCPGを満たしていない場合、例えば、全従業員に対してフィッシングに耐性のあるMFAを要求していない場合、その製造者はセキュア・バイ・デザインの製品を提供しているとは見なされない。 |
| The authoring organizations recognize that these changes are significant shifts in an 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 product may 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. | 4 一部の本作成組織は、ソフトウエアのサプライチェーンに関するセキュリ ティ保証を得るための別のアプローチを模索している。 |
| SECURE BY DEFAULT TACTICS | セキュア・バイ・デフォルト戦術 |
| In addition to adopting secure by design development practices, the authoring organizations recommend software manufacturers prioritize secure by default configurations in their products. These should strive to update products to conform to these practices as they are refreshed. For example: | セキュアな設計による開発手法の採用に加えて、本作成組織は、ソフトウ ェアメーカーに対し、自社製品のセキュアなデフォルト設定を優先するよう推奨する。ソフトウェア・メーカーは、製品が更新されるたびに、これらのプラクティスに準拠するよう更新に努めるべきである。例えば |
| • Eliminate default passwords. Products should not come with default passwords that are universally shared. To eliminate default passwords, the authoring 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 that many enterprise deployments are managed by administrators who have not protected their accounts with MFA. Given that administrators are high value targets, products should make MFA opt-out rather than opt-in. Further, the system should regularly prompt the administrator to enroll in MFA until they have successfully enabled it on their account. Netherlands’ NCSC has guidance that parallels CISA’s, visit their Mature Authentication Factsheet for more information. | • 特権ユーザに対して多要素認証（MFA）を義務付ける。多くの企業では、管理者がアカウントを MFA で保護していない。管理者は価値の高いターゲットであることを考えると、製品は MFA をオプトインではなくオプトアウトにすべきである。さらに、管理者が自分のアカウントで MFA を正常に有効にするまで、システムは定期的に MFA への登録を促すべきである。オランダの NCSC には、CISA のガイダンスと類似したガイダンスがある。 |
| • 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. | • シングルサインオン（SSO）。ITアプリケーションは、最新のオープン・スタンダードを介してシングルサインオン・サポートを実装すべきである。例えば、SAML（Security Assertion Markup Language）やOIDC（OpenID Connect）などがある。 |
| • 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 or confirmed security incident. Consider best practices such as providing easy integration with security information and event management (SIEM) systems with application programming interface (API) access that uses coordinated universal time (UTC), standard time zone formatting, and robust documentation techniques. | • 安全なログ。追加料金や追加設定なしで、高品質の監査ログを利用者に提供する。監査ログは、潜在的なセキュリティ・インシデントを検出してエスカレーションするために極めて重要である。また、セキュリティ・インシデントが疑われる、または確認された場合の調査中にも極めて重要である。セキュリティ情報・イベント管理（SIEM）システムとの容易な統合を、協定世界時（UTC）を使用するアプリケーション・プログラミング・インタフェース（API）アクセス、標準タイムゾーンフォーマット、堅牢な文書化技術によって実現するなどのベストプラクティスを考慮する。 |
| • Software Authorization Profile. Software suppliers should provide recommendations on authorized profile roles and their designated use case. Manufacturers should include a visible warning that notifies customers of an increased risk if they deviate from the recommended profile authorization. For example, medical doctors can view all patient records, but a medical scheduler has limited access to certain information that is required for scheduling appointments. | • ソフトウェア認可プロファイル。ソフトウェア供給者は,認可されたプロファイルの役割とその指定されたユースケースに関する推奨事項を提供すべきである。製造者は,推奨されるプロファイル権限から逸脱した場合,リスクが増大することを利用者に通知する目に見える警告を含めるべきである。例えば,医師はすべての患者記録を見ることができるが,医療スケジューラは予約に必要な特定の情報へのアクセスが制限されている。 |
| • Forward-looking security over backwards compatibility. Too often, backwards• compatible 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 recognize that shortened hardening guides result from ongoing partnership with existing customers and include efforts by many product teams, including user experience (UX). | • ハーデニングガイド」のサイズを追跡して削減する。製品に同梱される「ハーデニングガイド」のサイズを縮小し,ソフトウ ェアの新バージョンがリリースされるにつれてサイズが縮小するように努め る。ハーデニングガイド」の構成要素を製品のデフォルト構成として統合する。本作成組織は,短縮されたハーデニングガイドは既存利用者との継続的なパートナ ーシップから生まれたものであり,ユーザエクスペリエンス(UX) を含む多くの製品チームによる取り組みが含まれていることを認識する。 |
| • Consider the user experience consequences of security settings. Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats. | • セキュリティ設定がユーザエクスペリエンスに及ぼす影響について考えてみる。新しい設定が追加されるたびにエンドユーザの認知的負担が増加するため,それがもたらすビジネス上の利益と合わせて評価する必要がある。代わりに,最も安全な設定がデフォルトで製品に統合されるべきである。設定が必要な場合,デフォルトのオプションは,一般的な脅威に対して広く安全であるべきである。 |
| The authoring organizations acknowledge these changes may have operational effects on how the software is employed. Thus, customer input is critical in balancing operational and security considerations. We believe that developing written roadmaps and executive support that prioritize these ideas into an organization’s most critical products is the first step to shifting towards secure software development practices. While customer input is important, we have observed important cases where customers have been unwilling or unable to adopt improved standards, often network protocols. It is important for the manufacturers to create meaningful incentives for customers to stay current and not allow them to remain vulnerable indefinitely. | 本作成組織は、これらの変更がソフトウェアの使用方法に運用上の影響を及ぼす可能性があることを認識している。したがって、運用とセキュリ ティの考慮事項のバランスをとるためには、利用者の意見が不可欠である。このような考えを組織の最も重要な製品に優先的に反映させるロードマップを文書化し、経営陣の支持を得ることが、安全なソフトウエア開発手法に移行するための第一歩であると考える。利用者の意見は重要であるが、利用者が改善された標準（多くの場合、ネットワーク・プロトコル）を採用したがらないか、採用できない重要なケースを観察してきた。メーカーが、利用者に対して、いつまでも脆弱なままでいることを許さず、最新の状態を維持するための有意義なインセンティブを生み出すことが重要である。 |
| HARDENING VS LOOSENING GUIDES | ハーデニングガイドとルーズニング・ガイド |
| Hardening guides may result from the lack of product security controls being embedded into a product’s architecture from the start of development. Consequently, hardening guides can also be a roadmap for adversaries to pinpoint and exploit insecure features. It is common for many organizations to be unaware of hardening guides, thus they leave their device configuration settings in an insecure posture. An inverted model known as a loosening guide should replace such hardening guides and explain which changes users should make while also listing the resulting security risks. 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 business risk of decisions in plain, understandable language, and can raise organizational awareness of risks to malicious cyber intrusions. Security tradeoffs should be determined by the customers’ senior executives, balancing security with other business requirements. | 本作成組織は、製品の安全性を確保するための方法を列挙したハーデニングガイドを作成するのではなく、ソフトウエアメーカーがデフォルトで安全なアプローチに移行し、「ルースニング・ガイド」を提供することを推奨する。これらのガイドは、意思決定によるビジネスリスクをわかりやすい言葉で説明し、悪意のあるサイバー侵入に対するリスクに対する組織の意識を高めることができる。セキュリティのトレードオフは、セキュリティと他のビジネス要件のバランスを取りながら、利用者の上級幹部が決定すべきである。 |
| RECOMMENDATIONS FOR CUSTOMERS | 利用者への推奨事項 |
| The authoring organizations recommend organizations hold their supplying software manufacturers accountable for the security outcomes of their products. As part of this, the authoring organizations recommend that executives prioritize the importance of purchasing secure by design and secure by default products. This can manifest through establishing policies requiring that IT departments assess the security of software before it is purchased, as well as empowering IT departments to push back if necessary. IT departments should be empowered to develop purchasing criteria that emphasize the importance of secure by design and secure by default practices (both those outlined in this document and others developed by the organization). Furthermore, IT departments should be supported by executive management when enforcing these criteria in purchasing decisions. Organizational decisions to accept the risks associated with specific technology products should be formally documented, approved by a senior business executive, and regularly presented to the board of directors. | 本作成組織は、各組織に対し、供給元ソフトウェアメーカーが自社製品のセキュリ ティ上の結果について責任を負うことを推奨する。その一環として、セキュアな設計によるセキュアな製品、デフォルトでセキュアな製品を購入することの重要性を、経営幹部が優先的に認識することを推奨する。これは、IT部門が購入前にソフトウエアのセキュリ ティを評価することを義務付ける方針を確立することや、IT部門が必要に応じて背中を押す権限を与えることによって実現できる。IT部門には、セキュア・バイ・デザインとセキュア・バイ・デフォルト（本文書で概説したも のと、組織が開発した他の手法の両方）の実践の重要性を強調する購入基準を策定す る権限を与えるべきである。さらに、IT部門は、購買決定においてこれらの基準を実施する際、経営幹部の支援を受けるべきである。特定のテクノロジー製品に関連するリスクを受け入れるという組織の決定 は、正式に文書化し、上級経営幹部によって承認され、定期的に取締役会に提示されるべきである。 |
| Key enterprise IT services that support the organization’s security posture, such as the enterprise network, enterprise identity and access management, and security operations and response capabilities, should be seen as critical business functions that are funded to align with their importance to the organization’s mission success. Organizations should develop a plan to upgrade these capabilities to leverage manufacturers that embrace secure by design and secure by default practices. | 組織のセキュリティ体制を支援する主要なエンタープライズ IT サービス（エ ンタープライズネットワーク、エンタープライズ ID 及びアクセス管理、セキュリティ 運用及び対応機能など）は、重要なビジネス機能として捉え、組織のミッションの成 功に対する重要性に見合った資金を提供する。組織は、セキュア・バイ・デザインとセキュア・バイ・デフォルトを採用するメーカーを活用するために、これらの機 能をアップグレードする計画を策定すべきである。 |
| Where possible, organizations should strive to forge strategic relationships with their key IT suppliers. Such relationships include trust at multiple levels of the organization and provide vehicles to resolve issues and identify shared priorities. Security should be a critical element of such relationships and organizations should strive to reinforce the importance of secure by design and secure by default practices in both the formal (e.g ., contracts or vendor agreements) and informal dimensions of the relationship. Organizations should expect transparency from their technology suppliers about their internal control posture as well as their roadmap towards adopting secure by design and secure by default practices. | 可能であれば、組織は主要なITサプライヤーと戦略的な関係を構築するよう努め るべきである。このような関係には、組織の複数のレベル における信頼関係が含まれ、問題を解決し、優先事項を共有するための手段を提供する。セキュリティは、このような関係の重要な要素であるべきであり、組織は、関係の公式な側面 （契約やベンダー契約など）と非公式の側面の両方において、セキュア・バイ・デザインとセキュア・バイ・デフォルトの実践の重要性を強化するよう努めるべきである。組織は、セキュア・バイ・デザインとセキュア・バイ・デフォルトの実践に向けたロードマップだけでなく、内部統制の態勢についても、テクノロジーサプライヤから透明性が確保されることを期待すべきである。 |
| In addition to making secure by default a priority within an organization, IT leaders should collaborate with their industry peers to understand which products and services best embody these design principles. These leaders should coordinate their requests to help manufacturers prioritize their upcoming security initiatives. By working together, customers can help provide meaningful input to manufacturers and create incentives for them to prioritize security. | セキュア・バイ・デフォルトを組織内の優先事項とすることに加え、IT リーダーは、業界の同業者と協 力して、どの製品やサービスがこれらの設計原則を最もよく体現しているかを理解すべきである。これらのリーダーは、メーカーが今後のセキュリティ対策に優先順位をつけられるよう、要望を調整する必要がある。連携することで、利用者はメーカーに有意義な意見を提供し、メーカーがセキュリティを優先するインセンティブを生み出すことができる。 |
| When leveraging cloud systems, organizations should ensure they understand the shared responsibility model with their technology supplier. That is, organizations should have clarity on the supplier's security responsibilities rather than just the customer’s responsibilities. | クラウドシステムを活用する場合、組織は、テクノロジーサプライヤとの責任分担モデルを確実に理解する必要がある。つまり、企業は、利用者の責任だけでなく、サプライヤのセキュリティ責任についても明確にしておく必要がある。 |
| Organizations should prioritize cloud providers that are transparent about their security posture, internal controls, and ability to live up to their obligations under the shared responsibility model. | 組織は、自社のセキュリティ体制、内部統制、責任共有モデルの下での義務を果たす能力について透明性のあるクラウドプロバイダを優先すべきである。 |
| 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 specific commercial entities or commercial 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. | 本レポートの情報は、情報提供のみを目的として「現状のまま」提供されている。CISAおよび本作成組織は、分析対象を含め、いかなる商用製品またはサービスも推奨しない。サービスマーク、商標、製造者、その他による特定の営利団体または営利製品、プロセス、サービスへの言及は、CISAおよび執筆団体による承認、推奨、優遇を意味するものではない。本文書はCISAによる共同イニシアティブであり、自動的に規制文書としての役割を果たすものではない。 |
« 世界経済フォーラム (WEF) デジタルトラストの測定：信頼できるテクノロジーの意思決定を支援する (2023.10.03) | Main | JNSA ISOG-J セキュリティ対応組織の教科書 第3.1版 »
Comments