英国 意見募集:ソフトウェアベンダーのための実践規範 (2024.08.02)
こんにちは、丸山満彦です。
英国政府は、ソフトウェアの開発と流通における一般的な誤りを防止し、ソフトウェア・ベンダーとその顧客との情報共有を改善のために、ソフトウェアベンダーのための実践規範のドラフトを公表し、意見募集をしていますね...1週間と短いですね...
同時に発表されている「AIのサイバーセキュリティ」と連動しているようです...
● GOV.UK
・2024.08.02 A Code of Practice for Software Vendors: call for views
意見対象は次...
・2024.08.02 Call for views on the Code of Practice for Software Vendors
目次...
Contents | 目次 |
Executive summary | エグゼクティブサマリー |
Chapter 1: Introduction | 第1章:序文 |
Chapter 2: DSIT activity | 第2章:DSITの活動 |
Chapter 3: How organisations procuring software should use this Code of Practice | 第3章:ソフトウェアを調達する組織は、この実践規範をどのように利用すべきか |
Chapter 4: Voluntary Code of Practice for Software Vendors | 第4章:ソフトウェアベンダーのための自主規範 |
Chapter 5: Supporting materials | 第5章:参考資料 |
Chapter 6: How to respond to the call for views | 第6章:意見募集への対応方法 |
Annex A: Full Code of Practice | 附属書A:実施規範全文 |
Annex B: Implementation guidance example | 附属書B:実施ガイダンス例 |
Annex C: Call for views survey questionnaire | 附属書C:意見募集調査アンケート |
エグゼクティブサマリー...
Executive summary | エグゼクティブサマリー |
In January 2024, the Department for Science, Innovation and Technology (DSIT) published the government response to the call for views on software resilience and security for businesses and organisations. This response outlined the Government’s proposed policy package that aims to raise the baseline expectations of software security, and to improve software resilience across the UK. | 2024年1月、科学技術革新省(DSIT)は、企業・組織のためのソフトウェアのレジリエンスとセキュリティに関する意見募集に対する政府の回答を公表した。この回答では、ソフトウェア・セキュリティに対する基本的な期待を高め、英国全体のソフトウェア・レジリエンスを改善することを目的とした、政府の政策パッケージ案を概説した。 |
This document provides businesses with the opportunity to provide feedback on the Government’s primary proposed policy intervention that was developed in response to engagement with stakeholders: the Code of Practice for Software Vendors. | 本書は、利害関係者とのエンゲージメントに応じて策定された政府の主要な政策介入案である「ソフトウェア・ベンダーのための実施規範」に対するフィードバックを提供する機会を企業に提供するものである。 |
The Code of Practice for Software Vendors outlines the fundamental security and resilience measures that should reasonably be expected of all organisations that develop and / or sell software to organisational customers. It includes guidance on how software should be developed, built, deployed and maintained, and how vendors can communicate with effectively with customers that procure their software. In engaging with this Code of Practice, software vendors will significantly improve the cyber resilience of their product and services. | ソフトウェア・ベンダーのための実施規範」は、ソフトウェアを開発し、あるいは組織の顧客に販売するすべての組織に合理的に期待されるべき基本的なセキュリティとレジリエンスの対策を概説している。これには、ソフトウ ェアをどのように開発、構築、配備、保守すべきか、また、ベンダーがソフトウ ェアを調達する顧客とどのように効果的なコミュニケーションをとるべきか に関する指針も含まれている。この実践規範に取り組むことで、ソフトウェア・ベンダーは、その製品とサービスのサイバー・レジリエンスを大幅に改善することができる。 |
The Code of Practice is made up of 21 provisions over 4 principles: | この実施規範は、4つの原則を含む21の条項で構成されている: |
・Principle 1: Secure design and development: this principle ensures that the product or service is appropriately secure when provided. | ・原則1:安全な設計と開発:この原則は、製品やサービスがプロバイダとして提供される際に、適切に安全であることを保証する。 |
・Principle 2: Build environment security: this principle ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software. | ・原則2:ビルド環境のセキュリティ:この原則は、ビルド環境が危険にさらされるリスクを最小化し、ソフトウェアの完全性と品質を保護するための適切な措置が講じられていることを保証する。 |
・Principle 3: Secure deployment and maintenance: this principle ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities. | ・原則3:安全な配備と保守:この原則は、製品またはサービスがその耐用年数を通じて安全であり続け、脆弱性の可能性と影響を最小化することを保証する。 |
・Principle 4: Communication with customers: this principle ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management. | ・原則4:顧客とのコミュニケーション:この原則は、効果的なリスクマネジメントとインシデントマネジメントを可能にするために、ベンダー組織が十分な情報を顧客に提供することを保証する。 |
The Code of Practice, co-designed with industry leaders, academics, and technical experts from the National Cyber Security Centre, has been developed to support any organisation that develops and/or sells software to be sold to organisational customers (B2B). This includes organisations that sell solely software products or services, or organisations selling digital products or services that contain software. The government and co-creators have been mindful that organisations vary in size, capacity and resources, and organisations will have to engage in risk assessments to determine the most effective way in which they can follow this Code of Practice. Nevertheless, the Code of Practice provides clarity on key, underlying principles that represent best practices to help software vendors develop and distribute software securely. | この実施規範は、業界のリーダー、学者、National Cyber Security Centreの技術専門家と共同で策定したもので、組織の顧客(B2B)に販売するソフトウェアを開発・販売するあらゆる組織を支援するために作成された。これには、ソフトウェア製品やサービスのみを販売する組織や、ソフトウェアを含むデジタル製品やサービスを販売する組織が含まれる。政府と共同作成者は、組織の規模、能力、リソースがさまざまであることを念頭に置いており、組織は、この実施規範に従うための最も効果的な方法を決定するために、リスクアセスメントに取り組まなければならない。とはいえ、この実施規範は、ソフトウェアベンダーがソフトウェアを安全に開発・配布するためのベストプラクティスを代表する重要な基本原則を明確にするものである。 |
Technical controls and implementation guidance will be published alongside the Code of Practice. This will set out the minimum set of objective controls that a software vendor should demonstrate to provide confidence in the resilience of their software product or service as well as guidance to support organisations in identifying the best implementation options for them. | 技術的な管理と実装の手引きは、この「実施規範」とともに公表される予定である。これは、ソフトウェアベンダーが、そのソフトウェア製品やサービスのレジリエンスに対する信頼性を提供するために示すべき客観的な管理の最小限のセットと、組織にとって最適な実装オプションを特定するための支援ガイダンスを規定するものである。 |
This call for views aims to gather views on the market need for the Code of Practice for Software Vendors, the audience that this policy should be addressing, and the suitability of the Code and proposed supporting materials. | この意見募集は、ソフトウェアベンダーのための実施規範の市場ニーズ、この方針が取り組むべき対象者、実施規範と支援資料案の適合性について意見を集めることを目的としている。 |
・[PDF]
コードプラクティス...
Annex A: Full Code of Practice | 附属書 A:実施規範全文 |
Principle 1: Secure design and development | 原則1:安全な設計と開発 |
This principle ensures that the software product or service is appropriately secure when provided. | この原則は、ソフトウェア製品またはサービスがプロバイダとして提供される際に、適切にセキュアであることを保証するものである。 |
The Senior Responsible Officer in vendor organisations shall do the following: | ベンダ組織の上級責任者は、以下を実施しなければならない: |
1.1 Ensure the organisation follows an established secure development framework. | 1.1 組織が確立されたセキュアな開発フレームワークに従っていることを確認する。 |
1.2 Ensure the organisation understands the composition of their software products and services and that risks linked to the ingestion and maintenance of third-party components, including open-source components, are assessed throughout the lifecycle. | 1.2 組織がソフトウェア製品及びサービスの構成を理解し、オープンソースソフトウェアコンポーネントを含むサードパーティ製コンポーネントの取り込み及び保守に関連するリスクを、ライフサイクル全体を通じてアセスメントする。 |
1.3 Ensure the organisation has a clear process for testing software before distribution. | 1.3 組織は、配布前にソフトウェアをテストするための明確なプロセスを持っていることを確認する。 |
1.4 Ensure that the organisation follows secure by default principles throughout the development lifecycle of the product. | 1.4 組織が、製品の開発ライフサイクルを通じて、セキュアバイデフォルトの原則に従うことを確実にする。 |
The Senior Responsible Officer in vendor organisations should do the following: | ベンダ組織の上級責任者は、以下のことを行うべきである: |
1.5 Ensure secure by design principles are followed throughout the development process. | 1.5 開発プロセス全体を通じて、セキュアバイデザインの原則に確実に従う。 |
1.6 Encourage the use of appropriate security tools and technologies to make sure that the default options throughout development and distribution are secure. | 1.6 適切なセキュリティツールや技術の使用を奨励し、開発・配布のデフォルトオプショ ンがセキュアであることを確認する。 |
Principle 2: Build environment security | 原則 2: 構築環境のセキュリティ |
This principle ensures that the appropriate steps are taken to minimise the risk of build environments becoming compromised and protect the integrity and quality of the software. | この原則は、ビルド環境が危険にさらされるリスクを最小化し、ソフトウエアの完全性と品 質を保護するために適切な措置が取られることを保証するものである。 |
The Senior Responsible Officer in vendor organisations shall do the following: | ベンダー組織の上級責任者は、以下を実施するものとする: |
2.1 Ensure the build environment is protected against unauthorised access. | 2.1 ビルド環境が不正アクセスから確実に保護されるようにする。 |
The Senior Responsible Officer in vendor organisations should do the following: | ベンダ組織の上級責任者は、以下を実施すること: |
2.2 Ensure changes to the environment are controlled and logged. | 2.2 環境への変更が確実に管理され、履歴が記録されるようにする。 |
2.3 Ensure you are using a build pipeline you trust. | 2.3 信頼できるビルドパイプラインを使用していることを確認する。 |
Principle 3: Secure deployment and maintenance | 原則3:安全な配備と保守 |
This principle ensures that the product or service remains secure throughout its lifetime, to minimise the likelihood and impact of vulnerabilities. | この原則は、脆弱性の可能性と影響を最小化するために、製品またはサービスがその存続期間を通じて安全であり続けることを保証するものである。 |
The Senior Responsible Officer in vendor organisations shall do the following: | ベンダー組織の上級責任者は、以下を実施する: |
3.1 Ensure that software is distributed securely to customers. | 3.1 ソフトウェアが顧客に安全に配布されるようにする。 |
3.2 Ensure the organisation implements and publishes an effective vulnerability disclosure process. | 3.2 組織が効果的な脆弱性開示プロセスを実施し、公開することを確実にする。 |
3.3 Ensure the organisation has processes in place for proactively detecting and managing vulnerabilities in software components it uses and software it develops, including a documented process to assess the severity of vulnerabilities and prioritise responses. | 3.3 組織が、脆弱性の重大性を評価し、対応の優先順位を決定するための文書化されたプロセスを含め、使用するソフトウェアコンポーネント及び開発するソフトウェアの脆弱性を事前に検知し、管理するためのプロセスを備えていることを確実にする。 |
3.4 Ensure that vulnerabilities are appropriately reported to the relevant parties. | 3.4 脆弱性を関係者に適切に報告する。 |
3.5 Ensure the organisation provides timely security updates, patches and notifications to its customers. | 3.5 セキュリティアップデート、パッチ、通知をタイムリーに提供する。 |
Senior leaders in vendor organisations should do the following: | ベンダー組織のシニアリーダーは、次のことを行うべきである: |
3.6 Make a public affirmation that the organisation would welcome security researchers to test software products and services provided by the organisation as part of its vulnerability disclosure process. | 3.6 脆弱性公開プロセスの一環として、組織が提供するソフトウエア製品やサービスをセキュリ ティ研究者がテストすることを歓迎することを公言する。 |
Principle 4: Communication with customers | 原則4:顧客とのコミュニケーション |
This principle ensures that vendor organisations provide sufficient information to customers to enable effective risk and incident management. | この原則は、効果的なリスクマネジメントとインシデントマネジメントを可能にするために、ベンダ組織が 顧客に十分な情報を提供することを保証するものである。 |
Senior Responsible Officers in software vendor organisations shall do the following: | ソフトウェアベンダ組織の上級責任者は、以下を実施する: |
4.1 Ensure the organisation provides information to the customer, in an accessible way, specifying the level of support and maintenance provided for the software product/ service being sold. | 4.1 組織が、販売するソフトウェア製品/サービスに関して提供されるサポート及び保守のレベルを明記した情報を、利用しやすい方法で顧客に提供することを確実にする。 |
4.2 Ensure the organisation provides at least 1 year’s notice to customers, in an accessible way, of when the product or service will no longer be supported or maintained by the vendor. | 4.2 組織は、製品またはサービスがベンダによってサポートまたは保守されなくなる時期について、少なくとも1年前に、利用しやすい方法で顧客に通知することを確実にする。 |
4.3 Ensure information is made available to customers in an appropriate and timely manner about notable incidents that may cause significant impact to customer organisations. | 4.3 顧客組織に重大な影響を及ぼす可能性のある注目すべきインシデントについて、適切かつタイムリーな方法で顧客に情報が提供されるようにする。 |
Senior Responsible Officers in vendor organisations should do the following: | ベンダー組織の上級責任者は、以下のことを行うべきである: |
4.4 Ensure that high level information about the security and resilience standards, frameworks, organisational commitments and procedures followed by the organisation is made available to customers. | 4.4 組織が従うセキュリティ及びレジリエンスの標準、枠組み、組織のコミットメント及び 手続きに関するハイレベルの情報が顧客に提供されるようにする。 |
4.5 Ensure that the organisation proactively supports affected customers during and following a cyber security incident to contain and mitigate the impacts of an incident. How this would be done should be documented and agreed in contracts with the customer. | 4.5 組織が、サイバーセキュリティインシデント発生中及び発生後に、影響を受ける顧 客を積極的に支援し、インシデントの影響を抑制・軽減することを確実にする。その方法は、文書化し、顧客との契約で合意する。 |
4.6 Provide customer organisations with guidance on how to use, integrate, and configure the software product or service securely. | 4.6 ソフトウェア製品またはサービスを安全に使用、統合、設定する方法に関するガイダンスを顧客組織に提供する。 |
サンプル...
Annex B: Implementation guidance example | 附属書 B:実装ガイダンスの例 |
Below is an example of how the implementation guidance will be designed and structured. Work on the accompanying implementation guidance is ongoing, but the guidance will be published alongside the Code of Practice and technical controls detailed above. | 以下は、実施ガイダンスの設計と構成の例である。付随する実施ガイダンスの作成は現在進行中であるが、ガイダンスは、上記で詳述した実施規範および技術的管理とともに公表される予定である。 |
Principle 1: Secure design & development | 原則1:安全な設計と開発 |
Good security engineering means building technologies that remain usable and resilient throughout their lifetime, even in the face of a cyber attack. Achieving this outcome needs to begin in the design and development phase so that user need and security are baked into the product or service. Ensuring that engineering processes and practices minimise both the likelihood and possible impact of a security compromise plays an essential part in gaining assurance in vendor competence and the products and services producing. | 優れたセキュリティ工学とは、サイバー攻撃に直面しても、生涯を通じて使用可能でレジリエンスを維持できる技術を構築することである。この成果を達成するためには、設計・開発の段階から着手し、ユーザのニーズとセキュリティを製品やサービスに組み込む必要がある。セキュリティ侵害の可能性と起こりうる影響の両方を最小化するエンジニアリングプロセスと実践を確保することは、ベンダーの能力と製造される製品・サービスに対する保証を得る上で不可欠な役割を果たす。 |
Developers are not necessarily security experts and the security toolbox available to them can make it difficult to navigate cyber security technical complexities, leading to implementation mistakes that could have been avoided. The selection of the toolbox available to developers should therefore consider its usability and maintenance, as well as functionality and cost. This support to developers can be through access to experts, training, positive security cultures and processes as well as the availability of up-to-date tools. | 開発者は必ずしもセキュリティの専門家ではなく、利用可能なセキュリティツールボックスを利用することで、サイバーセキュリティの技術的な複雑性を理解することが難しくなり、回避できたはずの実装ミスにつながる可能性がある。そのため、開発者が利用できるツールボックスの選択は、機能やコストだけでなく、使いやすさや保守性も考慮する必要がある。開発者に対するこのような支援は、専門家へのアクセス、トレーニング、積極的なセキュリ ティ文化やプロセス、最新のツールの利用可能性などを通じて行うことができる。 |
By implementing the provisions in the Software Vendor Code of Practice, not only will the software product or service be more cyber resilient by default, but it will also be more stable and easier to maintain. | ソフトウェアベンダー規範」の規定を実施することで、ソフトウ ェア製品またはサービスは、デフォルトでよりサイバーレジリエンスに優れ るだけでなく、より安定し、保守も容易になる。 |
1.1 Ensure the organisation follows an established secure development framework. | 1.1 組織が確立された安全な開発フレームワークに従っていることを確認する。 |
Technical control: Follow a secure development framework. | 技術的な管理を行う: セキュアな開発フレームワークに従う。 |
Using a secure development framework across your engineering projects will provide a consistent and repeatable way to support developers to ensure security has been considered at the right time. They are proactive approaches to building security into a product or service that incorporate people, processes and technology aspects. By not following a secure development framework, important cyber security decisions may #be missing# and inevitably will need to be bolted on at the end of the development process and/or cause more cost during deployment. | エンジニアリングプロジェクト全体でセキュア開発フレームワークを使用するこ とにより、開発者を支援する一貫した反復可能な方法が提供され、適切な時点でセ キュリティが考慮されていることが確認される。セキュア開発フレームワークは、人、プロセス、技術の各側面から製品またはサービスにセ キュリティを組み込むための事前予防的なアプローチである。セキュアな開発フレームワークに従わない場合、重要なサイバーセキュリティに関する意思決定が欠落し、必然的に開発プロセスの最後に追加する必要が生じたり、導入時にコストが増大したりする可能性がある。 |
You may wish to publish a description of which framework you are using, and which controls have been implemented. You should be able to demonstrate conformance to a secure development framework across your development and deployment activities. | どのフレームワークを使用し、どのような管理策を導入したかを公表するとよい。開発および配備の活動全体にわたって、セキュアな開発フレームワークへの準拠を実証 できるべきである。 |
A good secure development framework should include the following topics as a minimum: | 優れたセキュア開発フレームワークには、最低限以下の項目を含めるべきである: |
Threat modelling – techniques used to understand how the product or service might be attacked or otherwise fail. | 脅威モデリング - 製品やサービスがどのように攻撃される可能性があ るか、あるいは他の方法で失敗する可能性があるかを理解するた めに使用される技術 |
Requirements capture – understanding and recording security and user needs. | 要件の収集 - セキュリティ及びユーザのニーズを理解し、記録する。 |
Governance and roles – how the approach to ensuring secure design & development is controlled and directed. | ガバナンスと役割 - 安全な設計・開発を確保するためのアプローチがどのように管理され、指揮されるか。 |
Test strategy – consistent approaches to verification that have sufficient rigour and coverage. | テスト戦略 - 十分な厳密性と網羅性を有する検証への一貫したアプロー チを行う。 |
Data management – understanding what data exists and how it should be appropriately protected throughout its lifecycle. | データ管理 - どのようなデータが存在し、ライフサイクルを通じてどのように 適切に保護されるべきかを理解する。 |
Configuration management – consistent approaches to tracking changes, implementing version control, and enabling reproducibility. | 構成管理 - 変更を追跡し、バージョン管理を実施し、再現性を可能にする一貫したアプローチ。 |
Which secure development framework you decide to use is a business decision based on what will fit best with the culture and existing processes of your organisation. There are many secure development frameworks available “off-the-shelf”, examples include: | どのセキュア開発フレームワークを使用するかは、組織の文化や既存のプロ セスに最も適合するものに基づいて、ビジネス上の意思決定を行う。多くのセキュア開発フレームワークが「既製品」として入手可能である: |
« 欧州AI法が施行された... (2024.08.01) | Main | TikTok 米国で親会社が児童プライバシー法違反で提訴され、欧州でデジタルサービス法遵守のためTikTok LiteリワードプログラムのEUからの恒久的撤退を約束 »
Comments