« 米国 GAO 消費者保護:議会は消費者ランク付けに使用されるスコアに関する保護の強化を検討すべき (2022.05.26) | Main | 米国 FBI サイバーセキュリティに関するボストン会議2022でのFBI長官の基調講演 »

2022.06.03

英国 防衛省 セキュア・バイ・デザイン要求

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

英国の防衛省が、セキュア・バイ・デザインを採用するよう、通知を出していますね。。。

リスク選好度を定義して、セキュリティ・コントロールを考えるというのは、ERMにも通じる話で、さすがISO/IEC 27001(元BS 7799)を生み出した国ですね。。。

日本が通産省の「安全対策認定事業所制度」を廃止し、新たに民間認証制度を導入する際に、思い切って安全対策基準から、国際標準になろうとしていたBS7799をベースにしたISMS認証基準に変えました。私の意見は、全くのコピーにしよう!でしたが、英国の基準であることから、同じというわけにもいかず、若干の変更に加えたISMS認証基準を作りました。。。(ただ、内容はほぼ同じでした。労働者のバックグラウンドチェックのような項目を省いたということをしたかもしれません。。。覚えていない。。。)

セキュア・バイ・デザインの考え方も参考になるので、是非、目を通してくださいませ。。。

 

● U.K. GovernanceMilitary equipment, logistics and technology - Guidance Industry Security Notice (ISN)

・2022.05.30 [PDF] Secure by Design Requirements

 

20220603-25225

 

 

Principle 1: Understand and Define Context 原則1:状況の把握と定義
Understand the capability’s cyber security context and how it will use and manage MOD data while achieving its primary business/operational outcome(s).  ケイパビリティのサイバーセキュリティコンテキストと、主要なビジネス/運用成果を達成しながらどのように防衛省データを使用・管理するかを理解する。
Principle 2: Plan the Security Activities 原則2:セキュリティ活動の計画
Establish security workstream of the capability, perform initial planning including assessment of cyber threat and potential risks while defining clear security requirements, validation and verification.  当該ケイパビリティに関するセキュリティのワークストリームを確立し、サイバー脅威及び潜在的なリスクの評価を含む初期計画を実施し、明確なセキュリティ要件、検証及び妥当性を定義する。
Principle 3: Implement Continuous Risk Management 原則3:継続的なリスクマネジメントの実施
Embed cyber security risk management into existing programme governance as a continuous process.  サイバーセキュリティリスクマネジメントを、継続的なプロセスとして、既存のプログラムガバナンスに組み込む。
Principle 4: Define Security Controls 原則4:セキュリティコントロールの定義
Define, architect and implement security control requirements to address risks identified. Reuse existing services and patterns where they exist.  特定したリスクに対処するためのセキュリティ管理要件を定義し、設計し、実装する。既存のサービスやパターンが存在する場合は、それらを再利用する。
Principle 5: Engage and Manage the Supply Chain 原則5:サプライチェーンへの関与と管理
Understand the supply chain role and risks posed, including how to ensure they meet their responsibilities and implement good security.  サプライチェーンが果たすべき役割とリスクを理解し、サプライチェーンがその責任を果たし、適切なセキュリティを実施する方法を理解する。
Principle 6: Assure, Verify and Test 原則6:保証、検証、テスト
Work with security experts to gain security assurance, test and validate throughout the capability’s lifecycle.  セキュリティ専門家と連携して、ケイパビリティ・ライフサイクルを通じてセキュリティ保証、テスト、検証を行う。
Principle 7: Enable Through Life Management 原則7:ライフマネジメントを通じた実現
Ensure continuous security monitoring and improvements, including ongoing assurance requirements are enabled, met and disposed.  継続的なセキュリティ監視と改善、及び要求事項の実現・充足・破棄の保証を確実に行う。

 

 

 

Industry Security Notice  業界セキュリティ通知 
Number 2022/04 Subject: Secure by Design Requirements  番号 2022/04 件名:セキュア・バイ・デザイン要求
Introduction  はじめに 
1. This ISN is to inform the UK Defence Supply Base of the Secure by Design policy and approach which has been set out to ensure cyber secure delivery of capabilities.  1. この業界セキュリティ通知は、サイバーセキュアなケイパビリティ提供を保証するために定められたセキュア・バイ・デザインの方針とアプローチについて、英国国防供給基盤に通知するためのものである。
2. It applies to the definition, acquisition, development, maintenance and disposal of information-based capabilities for MOD. This includes but is not limited to networks, applications, services, information technology, operational technology, platforms and weapons systems.  2. 防衛省 のための情報ベースのケイパビリティの定義、取得、開発、保守及び廃棄に適用される。これには、ネットワーク、アプリケーション、サービス、情報技術、運用技術、プラットフォーム及び兵器システムが含まれるが、これらに限定されない。
Issue  課題 
3. MOD is currently in a transition period from Accreditation to the Secure by Design approach. As such:  3. 防衛省 は現在、認定からセキュア・バイ・デザイン アプローチへの移行期間中である。そのため 
a.      For MOD projects starting now: The Secure by Design approach outlined in this ISN should be followed.  a.      今から始める防衛省プロジェクトについて、このISNに概説されているセキュア・バイ・デザインのアプローチに従うべきである。
b.      For MOD projects currently in progress (unless otherwise advised by your Cyber Security Assessor):  b.      現在進行中の防衛省プロジェクトについて(サイバーセキュリティアセッサーから特にアドバイスがない限り)、
i.        the accreditation process should continue to be followed; and  i.        認定プロセスを継続すべきである。
ii.       a review of activities against the Secure by Design approach must be performed, in order to address gaps and inconsistencies.  ii.       ギャップや矛盾に対処するために、セキュア・バイ・デザインのアプローチに照らして活動をレビューする必要がある。
Background  背景 
4. The implementation of Secure by Design is intended to enable a culture of proactive risk management and security consideration throughout a capability’s lifecycle; by using cyber security principles, roles, processes, tools and techniques to secure systems and data; thereby ensuring Defence is better protected from cyber threats.  4. セキュア・バイ・デザインの実施は、ケイパビリティ・ライフサイクルを通じて、サイバーセキュリティの原則、役割、プロセス、ツール、テクニックを用いてシステムやデータを保護し、それによって国防をサイバー脅威からより確実に保護することにより、積極的にリスクを管理しセキュリティを考慮する文化を可能にすることを意図している。
5. MOD defines Secure by Design as:  5. 防衛省はセキュア・バイ・デザインを次のように定義している。
“An approach that enables a culture of proactive risk management and appropriate security consideration throughout a capability’s lifecycle by connecting cyber security principles, roles, processes, tools and techniques to achieve secure systems.”  "安全なシステムを実現するために、サイバーセキュリティの原則、役割、プロセス、ツール、技術を結びつけることにより、ケイパビリティ・ライフサイクルを通じて、積極的なリスク管理と適切なセキュリティ配慮の文化を可能にするアプローチ" 
6. The Secure by Design approach[1] is based upon the following seven principles (the requirements for which are set out within this ISN):  6. セキュア・バイ・デザインアプローチ[1] は、以下の7つの原則に基づいている(その要件は本業界セキュリティ通知に記載されている)。
Principle 1: Understand and Define Context 原則1:状況の把握と定義
Understand the capability’s cyber security context and how it will use and manage MOD data while achieving its primary business/operational outcome(s).  ケイパビリティのサイバーセキュリティコンテキストと、主要なビジネス/運用成果を達成しながらどのように防衛省データを使用・管理するかを理解する。
Principle 2: Plan the Security Activities 原則2:セキュリティ活動の計画
Establish security workstream of the capability, perform initial planning including assessment of cyber threat and potential risks while defining clear security requirements, validation and verification.  当該ケイパビリティに関するセキュリティのワークストリームを確立し、サイバー脅威及び潜在的なリスクの評価を含む初期計画を実施し、明確なセキュリティ要件、検証及び妥当性を定義する。
Principle 3: Implement Continuous Risk Management 原則3:継続的なリスクマネジメントの実施
Embed cyber security risk management into existing programme governance as a continuous process.  サイバーセキュリティリスクマネジメントを、継続的なプロセスとして、既存のプログラムガバナンスに組み込む。
Principle 4: Define Security Controls 原則4:セキュリティコントロールの定義
Define, architect and implement security control requirements to address risks identified. Reuse existing services and patterns where they exist.  特定したリスクに対処するためのセキュリティ管理要件を定義し、設計し、実装する。既存のサービスやパターンが存在する場合は、それらを再利用する。
Principle 5: Engage and Manage the Supply Chain 原則5:サプライチェーンへの関与と管理
Understand the supply chain role and risks posed, including how to ensure they meet their responsibilities and implement good security.  サプライチェーンが果たすべき役割とリスクを理解し、サプライチェーンがその責任を果たし、適切なセキュリティを実施する方法を理解する。
Principle 6: Assure, Verify and Test 原則6:保証、検証、テスト
Work with security experts to gain security assurance, test and validate throughout the capability’s lifecycle.  セキュリティ専門家と連携して、ケイパビリティ・ライフサイクルを通じてセキュリティ保証、テスト、検証を行う。
Principle 7: Enable Through Life Management 原則7:ライフマネジメントを通じた実現
Ensure continuous security monitoring and improvements, including ongoing assurance requirements are enabled, met and disposed.  継続的なセキュリティ監視と改善、及び要求事項の実現・充足・破棄の保証を確実に行う。
Roles and Responsibilities  役割と責任 
The following roles and responsibilities are pertinent to the Secure by Design approach:  セキュア・バイ・デザインのアプローチには、次のような役割と責任がある。
Capability Sponsors ケイパビリティ・スポンサー
Responsible for the sponsorship of the capability, its requirement development, concept of operation and ensuring the capability can address the risks in-service.  ケイパビリティのスポンサーシップ、要件開発、運用コンセプト、およびケイパビリティが稼働中のリスクに対処できることを保証する責任を負います。
Senior Responsible Owners (SROs) 上級責任者(SROs)
Accountable for the delivery of cyber secure outcomes throughout the capability lifecycle.  ケイパビリティ・ライフサイクルを通じて、サイバーセキュアな成果を実現するための責任を負う。
Delivery Team Leaders デリバリーチームリーダー
Responsible for the development and delivery of capabilities.  ケイパビリティの開発・提供に責任を持つ。
Capability Owners ケイパビリティ・オーナー
The in-service owners of the capability, responsible for ensuring the capability’s ability to protect relevant MOD data throughout its lifecycle.  ケイパビリティ・ライフサイクルを通じて、関連する国防総省のデータを保護するケイパビリティを確保する責任を負う、ケイパビリティの稼働中の所有者。
Commercial Officers コマーシャルオフィサー
Responsible for the implementation of contract terms and conditions in the MOD.  防衛省における契約条件の履行を担当。
Delivery Team Security Leads[2] デリバリーチーム セキュリティリード[2]
The individuals within the Delivery Team responsible for the overall design and implementation of security controls to mitigate the risks identified. They are the security SME on the Delivery Team.   特定されたリスクを軽減するためのセキュリティコントロールの全体的な設計と実装を担当するデリバリーチーム内の個人。デリバリーチーム内のセキュリティSMEである。
Cyber Security Assessor[3] サイバーセキュリティアセッサー[3]
Responsible for second line assessment of Delivery Teams adherence to Secure by Design and relevant risk and security policies and standards. They coordinate between Delivery Teams dealing with similar security challenges to optimise solutions and minimise duplication of effort; and are responsible for consistent and coherent advice and support to relevant capabilities.  デリバリーチームがセキュア・バイ・デザインや関連するリスク、セキュリティポリシー、標準を遵守しているかどうかをセカンドラインで評価する役割を担っています。同様のセキュリティ課題に取り組むデリバリーチーム間の調整を行い、ソリューションを最適化し、労力の重複を最小化する。また、関連するケイパビリティに対して一貫性のある首尾一貫したアドバイスとサポートを行う。
7. Industry partners must ensure they are aware of the individuals assigned to be above roles at the start of the project. Where are role is yet to be assigned, the Capability Sponsor must be contacted for advice.  7. 産業界のパートナーは、プロジェクトの開始時に上記の役割に割り当てられた個人を認識していることを確認しなければならない。役割がまだ割り当てられていない場合、助言のためにケイパビリティ・スポンサーに連絡しなければならない。
Governance  ガバナンス 
8. The Capability Sponsor must ensure a Senior Responsible Owner (SRO) is appointed to the project from the outset with the necessary skills and experience to fulfil the role.  8. ケイパビリティ・スポンサーは、その役割を果たすために必要なスキルと経験を持つ上級責任者(SRO)が、最初からプロジェクトに任命されていることを確認しなければならない。
9. The SRO must ensure that:  9. 上級責任者 は、以下を確保しなければならない。
a.      all decisions regarding the capability’s development and use are made in the context of the risk[4] facing MOD’s data and capabilities, and its resultant impact should it be realised;  a.      ケイパビリティの開発と使用に関するすべての決定は、防衛省のデータとケイパビリティが直面しているリスク([4] )と、それが実現した場合の結果的な影響との関連で行われます。
b.      a capability cyber risk appetite is defined and published for the Delivery Team; and  b.      デリバリーチームのために、ケイパビリティ・サイバー・リスク許容度を定義し、公表すること。
c.      Delivery Teams follow the Secure by Design requirements, or that accreditation activities are completed.  c.      デリバリーチームがセキュア・バイ・デザインの要件に従っていること、または認定活動が完了していること。
10. The Capability Sponsor must ensure that business cases, and any relevant submissions, adequately address security requirements. These must be funded and actioned through the capability’s lifecycle.  10. ケイパビリティ・スポンサーは、ビジネスケース及び関連する提出物が、セキュリティ要件に適切に 対応していることを確認しなければならない。これらは、ケイパビリティ・ライフサイクルを通じて資金調達され、実行されなければならない。
Principle 1: Understand and Define the Context  原則1:状況の把握と定義
11. Understanding the cyber security context of a capability as early as possible in the capability lifecycle will ensure that Capability Sponsors, SROs and Delivery Teams can identify the cyber security activities required to deliver successful outcomes. This drives future planning, resourcing and costing accuracy.  11.ケイパビリティ・ライフサイクルのできるだけ早い時期にケイパビリティのサイバーセキュリティ状況を理解することで、ケイパビリティ・スポンサー、上級責任者、及び、デリバリーチームが、成果をあげるために必要なサイバーセキュリティ活動を特定できるようになる。これは、将来の計画、人員配置、コスト計算の精度を高める。
12. Capability Sponsors must have a clearly documented context, purpose and mode of operation for the capability. This must be handed over to the Delivery Team Leader for further development and maintenance, and should include the following as a minimum:  12. ケイパビリティ・スポンサーは、ケイパビリティのコンテキスト、目的、運用方法を明確に文書化する必要がある。これは、さらなる開発・保守のためにデリバリーチームリーダーに引き渡されなければならず、最低限以下の内容を含んでいなければならない。
a.      Capability’s use;  a.      ケイパビリティの用途 
b.      The risk appetite;  b.      リスク選好度
c.      High level risks;  c.      高いレベルのリスク 
d.      Who will operate the capability and the support requirements;  d.      誰がそのケイパビリティを運用し、どのようなサポートが必要なのか。
e.      Data access, storage and processing requirements;  e.      データへのアクセス、保存、処理の要件。
f.        The role of suppliers; and  f.        サプライヤーの役割、および 
g.      The capability’s end-to-end operation and interdependencies.  g.      ケイパビリティのエンド・ツー・エンドの運用と相互依存性。
Initial Cyber Security Risk Assessment  サイバーセキュリティのリスクアセスメント 
13. Capability Sponsors must ensure an initial cyber security risk assessment is completed and documented accordingly. This risk assessment must be used by the Delivery Team Leader to plan the security activities.  13. ケイパビリティ・スポンサーは、初期のサイバーセキュリティリスク評価が完了し、それに従って文書化されることを確実にしなければならない。このリスクアセスメントは、デリバリーチームリーダーがセキュリティ活動を計画するために使用されなければならない。
Define the Risk Appetite  リスク選好度の定義 
14. The SRO must ensure that a capability risk appetite is defined and published, derived from relevant MOD risk appetite statements as a minimum threshold.  14. 上級責任者 は、最低限必要な閾値として、関連する 防衛省 のリスク選好度声明から導き出されたケイパビリティ・リスク選好度が定義・公表されていることを確認しなければならない。
Capability Registration  ケイパビリティ登録 
15. Delivery Teams Security Leads must register their capability with Cyber Defence & Risk (CyDR) by recording the capability on the CyDR provided security support tool.  15. デリバリーチームのセキュリティリーダーは、サイバーディフェンス&リスク(CyDR)が提供するセキュリティサポートツールにケイパビリティを記録することで、サイバーディフェンス&リスクにケイパビリティを登録する必要がある。
Principle 2: Plan the Security Activities  原則2:セキュリティ活動の計画 
16. The planning Principle is focused on establishing the security activities throughout a capability’s lifecycle.  16. 「計画原則」は、ケイパビリティ・ライフサイクルを通じたセキュリティ活動の確立に重点を置いている。
17. Delivery Team Leaders must:  17. デリバリーチームリーダーは、以下のことを行う必要がある。
a.      appoint a Delivery Team Security Lead;  a.      デリバリーチームのセキュリティリーダーを任命する。
b.      where required, establish a wider security team to provide advice and support;  b.      必要な場合は、アドバイスとサポートを提供するために、より広いセキュリティチームを設立する。
c.      establish security activities, including the assurance and testing approaches;  c.      保証とテストのアプローチを含む、セキュリティ活動を確立する。
d.      establish a continuous risk assessment approach throughout the lifecycle;  d.      ライフサイクルを通じて継続的にリスク評価を行う手法を確立する。
e.      identify good practice controls, architecture and design;  e.      グッドプラクティスのコントロール、アーキテクチャ、設計を特定する。
f.       engage with key stakeholders to ensure security outcomes are understood and appropriately implemented throughout the lifecycle;  f.       主要な利害関係者と連携し、ライフサイクルを通じてセキュリ ティ成果が理解され、適切に実施されるようにする。
g.      embed security into governance, funding, delivery and engineering practices; and  g.      ガバナンス、資金調達、納品、エンジニアリングの各業務にセキュリティを組み込む。
h.      ensure the handover from Delivery Team to service management factors in the cost of maintaining security through life.  h.      デリバリーチームからサービスマネジメントへの引継ぎの際に、セキュリティを生涯にわたって維持するためのコストを考慮するようにする。
18. All individuals assigned to the project must be suitably qualified and experienced.  18. プロジェクトにアサインされるすべての個人は、適切な資格と経験を有している必要がある。
Security Approach  セキュリティへの取り組み 
19. Delivery Team Security Leads must:  19. デリバリーチームのセキュリティリードは、以下のことを行う必要がある。
a.      define the security approach for the project, including:  a.      以下を含む、プロジェクトのセキュリティアプローチを定義する。
i.        the selection of a suitable risk assessment method, which must be adequate for the complexity and risk facing the capability; and  i.        適切なリスクアセスメント手法の選択。これは、そのケイパビリティが直面する複雑さとリスクに対して適切でなければならない。
ii.      the identification of a control framework (e.g. NIST) based on the scope and breadth of the capability (in terms of the technology it utilises, the processes it requires, and the culture and behaviours needed to support it);  ii.      ケイパビリティの範囲と広がり(利用する技術、必要とするプロセス、それをサポートするために必要な文化や行動の観点から)に基づく管理フレームワーク(NISTなど)の特定。
b.      ensure that all security risks[5] are recorded in the capability’s risk register and translated into appropriate language in order to allow the business to make an informed decision; and  b.      すべてのセキュリティリスク[5]がケイパビリティのリスク登録に記録され、ビジネスが十分な情報を得た上で判断できるように適切な言語に翻訳されていることを確認すること、及び 
c.      ensure stakeholders understand their role in maintaining the security posture.  c.      利害関係者が、セキュリティ態勢の維持における自らの役割を理解するようにする。
20. Delivery Team Leaders must document the security approach in a Security Definition and Management Document (SDMD), as outlined in Annex A. This document must be maintained during the life of the capability and transferred to the Capability Owner prior to the capability entering service.  20. この文書は、ケイパビリティの有効期間中維持され、ケイパビリティが使用される前にケイパビリティ所有者に転送されなければならない。
Principle 3: Implement Continuous Risk Management  原則3:継続的なリスクマネジメントの実施 
21. Cyber security risk management is the mechanism used for risk decisions to be taken and for the SRO and Delivery Team to understand what risks need to be addressed and managed.  21. サイバーセキュリティリスク管理は、リスクに関する意思決定を行い、上級責任者とデリバリーチームがどのようなリスクに対処し管理する必要があるかを理解するために使用されるメカニズムである。
22. SROs must ensure that cyber risks are actively managed throughout the capability lifecycle to ensure delivery is within defined MOD risk appetite and capability delivery risk management.  22. 上級責任者 は、ケイパビリティ・ライフサイクルを通じてサイバーリスクを積極的に管理し、防衛省のリスク許容度とケイパビリティ提供のリスク管理の範囲内で提供されることを保証しなければならない。
23. Risk analysis should be continuous throughout the capability lifecycle, this may be assured by specialist cyber security teams through routine assessment.  23. リスク分析は、ケイパビリティ・ライフサイクルを通じて継続的に行われる必要がある。これは、日常的な評価を通じて、サイバーセキュリティの専門チームによって保証されるかもしれない。
24. Delivery Team Leaders must ensure that cyber risk assessments are carried out and documented in a risk register and regularly reviewed. They should consider the capability’s interaction with other capabilities.  24. デリバリーチームリーダーは、サイバーリスクアセスメントが実施され、リスクレジスターに文書化され、定期的にレビューされることを保証しなければならない。彼らは、そのケイパビリティと他のケイパビリティとの相互作用を考慮する必要がある。
25. The risk register must:  25. リスク登録は、
a.       be created, maintained and managed throughout the capability’s lifecycle;  a.       ケイパビリティ・ライフサイクルを通じて作成、維持、管理される。
b.      include all controls used to mitigate risks;  b.      リスクを軽減するために使用されるすべてのコントロールを含める。
c.       indicate a clear accountable owner for all risks; and  c.       すべてのリスクについて、明確な責任者を示す。
d.      identify the risk to be transferred and managed as the capability goes into service.  d.      ケイパビリティの運用開始に伴い、移転・管理すべきリスクを特定する。
26. The risk register is intended to provide oversight, guidance, and analysis across multiple capabilities and allow for MOD to understand systemic risk. As such, it must be made available to specialist cyber security teams, 3rd line auditors (e.g. Defence Internal Audit, CyDR), Infrastructure and Projects Authority (IPA) and TLB security teams.  26.リスク登録は、複数のケイパビリティにわたって監視、指導、分析を提供し、防衛省がシステムリスクを理解できるようにすることを意図している。そのため、サイバーセキュリティの専門チーム、第三線の監査人(防衛内部監査、CyDRなど)、インフラ・プロジェクト局(IPA)、TLBセキュリティチームが利用できるようにしなければならない。
Review Frequency  レビュー頻度 
27. Delivery Team Security Leads must perform regular reviews of cyber risk with the Delivery Team Leader and where required Cyber Security Assessors. The frequency of these must be appropriate to the risks identified but must be quarterly as a minimum.  27. デリバリーチームのセキュリティリーダーは、デリバリーチーム リーダー及び、必要な場合はサイバーセキュリティアセッサーと共に、サイバーリスクの定期的なレ ビューを実施しなければならない。その頻度は、特定されたリスクに応じて適切でなければならないが、最低でも四半期ごとでなければならない。
Principle 4: Define Security Controls  原則4:セキュリティコントロールの定義 
28. Understanding the capability’s context and security goals will inform the security architecture and proportionate control selection.  28. ケイパビリティの文脈とセキュリティ目標を理解することは、セキュリティアーキテクチャーと比例制御の選択に情報を与える。
29. Delivery Teams Leads must ensure capabilities are designed in accordance with NCSC Good Design Guidance (Annex B) and use MOD approved architectural design patterns and standard tooling as default where this is available and applicable.  29. デリバリーチームのリーダーは、NCSCグッドデザインガイダンス(付属書B)に従ってケイパビリティが設計され、利用可能で適用可能な場合には、デフォルトとして防衛省承認済みアーキテクチャデザインパターンと標準ツールを使用することを保証しなければならない。
30. Existing processes, knowledge, standards and technologies should be identified, assessed and reused where possible to avoid duplication of effort.  30. 既存のプロセス、知識、標準、技術を特定し、評価し、可能な限り再利用して、労力の重複を避けるべきである。
Control Identification  コントロール識別 
31. Delivery Team Leaders must select appropriate controls to mitigate security risks to ensure compromise and disruption from cyber-attack is difficult, detection is easy and impacts are reduced.  31. デリバリーチームリーダーは、セキュリティリスクを軽減するために、サイバー攻撃による侵害と混乱を困難にし、発見を容易にし、影響を低減するための適切なコントロールを選択しなければならない。
32. All controls must be implemented at a level that is proportionate for the criticality of the capability and the data used. Delivery Teams can use control frameworks (such as NIST SP800-53, ISO 27000 series) to help understand relevant control options.  32. すべてのコントロールは、ケイパビリティの重要性と使用するデータに見合ったレベルで実施する必要がある。デリバリーチームは、コントロールフレームワーク(NIST SP800-53、ISO 27000シリーズなど)を使用して、関連するコントロールオプションの理解に役立てることができる。
Principle 5: Engage and Manage the Supply Chain  原則5:サプライチェーンへの関与と管理 
33. MOD relies on an extensive supply chain to deliver and maintain its capabilities. The security of a capability will only be as good as the security requirements defined in the contract that delivers that capability.  33. 防衛省は、そのケイパビリティを提供し維持するために、広範なサプライチェーンに依存している。ケイパビリティのセキュリティは、そのケイパビリティを提供する契約で定義されたセキュリティ要件と同程度のものでしかない。
34. The Delivery Team Leader, on behalf of the SRO, owns the relationship with the supplier and associated risks posed to the data used; they should foster a secure by design culture in the supply chain.  34. デリバリーチームリーダーは、上級責任者 を代表して、サプライヤーとの関係及び使用されるデータ にもたらされる関連リスクを所有し、サプライチェーンにおいてセキュア・バイ・デザインの文化を育むべきである。
35. Delivery Team Leaders must ensure supply chain security risks are adequately addressed throughout procurement and in all contractual arrangements. These include handling MOD data, providing services, developing, manufacturing and/or implementing capabilities. This must include, as a minimum:  35. デリバリーチームリーダーは、調達全体及びすべての契約上の取決めにおいて、サプライチェーンセキュリティリスクが適切に対処されていることを確認しなければならない。これには、国防総省のデータの取扱い、サービスの提供、ケイパビリティの開発、製造及び/又は実装が含まれる。これには、最低限以下のものが含まれなければならない。
a.       Through life capability security requirements;  a.       スルー・ライフ・ケイパビリティ・セキュリティ要件 
b.      Application of the DCPP[6] processes; and  b.      DCPP[6] プロセスの適用。
c.       Tender evaluation of security approaches.  c.       セキュリティアプローチに関する入札評価 
36. Commercial Officers must ensure contracts include:  36. コマーシャル・オフィサーは、契約に以下の内容が含まれていることを確認する必要がある。
a.       Clear and unambiguous through life security requirements, including the unencumbered transfer of data at contract end,  a.       契約終了時のデータ移行を含む、生涯を通じた明確で曖昧さのないセキュリティ要件。
b.      DEFCON 658 or equivalent;  b.      DEFCON 658または同等品 
c.       The right to access information relevant to a security investigation; and  c.       セキュリティ調査に関連する情報にアクセスする権利、および 
d.      Penalties, recovery and remedial actions to be applied in the event of a security breach. (See DEFCON 514).  d.      セキュリティ侵害が発生した場合に適用される罰則、回復、是正措置。(DEFCON514を参照)。
Principle 6: Assure, Verify and Test  原則6:保証、検証、テスト 
37. Delivery Team Leaders must demonstrate to the SRO and Cyber Security Assessor that security risks are adequately mitigated and deliver within the stated Risk Appetite. This must be carried out throughout the lifecycle before MOD data is used and before capabilities ‘go live’.  37. デリバリーチームリーダーは、セキュリティリスクが適切に緩和され、規定のリスク選好度内で提供されていることを上級責任者とサイバーセキュリティアセッサーに証明しなければならない。これは、国防総省のデータが使用される前、そしてケイパビリティが「稼動」する前に、ライフサイクルを通じて実施されなければならない。
38. Where the capability interacts with third parties outside of MOD, coordination between relevant authorities is required.  38. ケイパビリティが 防衛省 以外の第三者と相互作用する場合、関係当局間の調整が必要である。
39. Delivery Team Leaders must ensure that:  39. デリバリーチームリーダーは、以下のことを確認しなければならない。
a.       security requirements and controls are validated and verified at the most appropriate design points in the capability’s lifecycle;  a.       セキュリティ要件とコントロールは、ケイパビリティ・ライフサイクルの中で最も適切な設計ポイントで検証され、確認される。
b.      acceptance tests evaluate the security controls and functions; and  b.      受入テストにより、セキュリティ管理及び機能を評価する。
c.       Non-conformances are addressed before the capability can handle MOD data.  c.       不適合は、機能が防衛省データを扱えるようになる前に対処する。
40. Delivery Team Leaders must ensure findings from security tests, including vulnerability analysis, are reviewed and appropriately acted upon. These must be made available to Cyber Security Assessors for reference and pan-defence vulnerability analysis.  40. デリバリーチームリーダーは、脆弱性分析を含むセキュリティテストから得られた知見がレビューされ、適切に対処されることを保証しなければならない。これらは、サイバーセキュリティアセッサーが、参照や汎防衛的な脆弱性分析に利用できるようにしなければならない。
41. Where possible Delivery teams should seek to make security testing repeatable through automated testing or integrate as part of wider ‘bug bounty’ process.  41. 可能であれば、納品チームは、自動テストによってセキュリティテストの再現性を高めるか、より広範な「バグバウンティ」プロセスの一部として統合することを目指すべきである。
Principle 7: Enable Through Life Management  原則7:ライフマネジメントを通じた実現
42. Security does not stop once the capability is deployed. To ensure that capabilities remain resilient, vulnerabilities are fixed promptly, and the security posture is maintained, a continuous assessment of security performance is needed.  42. セキュリティは、ケイパビリティが配備された時点で終了するわけではない。ケイパビリティの回復力を維持し、脆弱性を迅速に修正し、セキュリティ姿勢を維持するためには、セキュリティ性能の継続的な評価が必要である。
43. SROs must implement a through life approach to security utilising the Defence Lines of Development (DLOD) approach and a culture of learning from experience. They must demonstrate that they are actively seeking security improvements.  43. 上級責任者は、防衛ライン開発(DLOD)アプローチと経験から学ぶ文化を活用し、セキュリティに対するスルーライフアプローチを実施しなければならない。上級責任者 は、セキュリティの改善を積極的に求めていることを実証しなければならない。
44. On behalf of the SRO, Capability Owners and Delivery Team Leaders must continuously reassess capability risks against functional changes, vulnerabilities and threats. They must act promptly to establish a mechanism to maintain the security posture of the capability.  44. 上級責任者を代表して、ケイパビリティ所有者とデリバリーチームリーダーは、機能の変更、脆弱性、脅威に対するケイパビリティリスクを継続的に再評価しなければならない。彼らは、ケイパビリティのセキュリティ態勢を維持するためのメカニズムを確立するために、速やかに行動しなければならない。
Validity / Expiry Date  有効期間/有効期限 
45. This ISN will expire when superceded or withdrawn.  45. このISNは、上書きされるか撤回されると失効する。
MOD Point of Contact Details  防衛省の連絡先詳細 
46. The point of contact in respect of this ISN is:  46. このISNに関する窓口は、以下の通り。
Info & Info-Cyber Policy Team Info & Info-Cyber Policy Team
Directorate of Cyber Defence & Risk (CyDR) Directorate
of Cyber Defence & Risk (CyDR)
Ministry of Defence 防衛省
email: UKStratComDD-CyDR-InfoCyPol@mod.gov.uk (Multiuser).  メールアドレス:UKStratComDD-CyDR-InfoCyPol@mod.gov.uk (Multiuser). 
Annexes:  アネックス 
1. Security Definition and Management Document  1. セキュリティの定義と管理に関する文書 
2. NCSC Good Design Guidance  2. NCSCグッドデザインガイダンス 
ISN 2022/04 Annex A  ISN 2022/04 附属書A 
Security Definition and Management Document  セキュリティの定義と管理に関する文書 
1. The Security Definition and Management Document (SDMD) must as a minimum:  1. セキュリティ定義・管理文書(SDMD)は、最低限必要なものである。
a.       Define:  a.       定義
i.        The use of the capability;  i.        ケイパビリティの使い道
ii.      A description of the capability’s relationship with and dependencies on other capabilities;  ii.      ケイパビリティと他のケイパビリティとの関係および依存性の説明
iii.     The Roles and Responsibilities involved in developing and managing the capability throughout its lifecycle including reporting points within CyDR;  iii.     CyDR内の報告ポイントを含め、ライフサイクルを通してケイパビリティの開発と管理に関わる役割と責任
iv.     External policies or standards that the capability needs to be compliant with and that will influence security e.g. air worthiness, safety, nuclear; and  iv.     ケイパビリティが準拠する必要があり、セキュリティに影響を与える外部の政策や基準(例えば、耐空性、安全性、原子力など)
v.      The Stakeholders and any external requirements e.g. data protection, NCSC assurance requirements.  v.      ステークホルダーと外部要件(データ保護、NCSC保証要件など)
b.      Set out: b.      設定
i.        The risk and assurance approach for the capability with key decision points;  i.        ケイパビリティに関するリスクと保証のアプローチと重要な決定点
ii.      The overall approach to security considering the threat, vulnerabilities and risk assessment;  ii.      脅威、脆弱性、リスクアセスメントを考慮したセキュリティの全体的なアプローチ
iii.     The role and structure of the supply chain and how supply chain risks will be managed; and  iii.     サプライチェーンの役割と構造、およびサプライチェーンのリスクをどのように管理するか
iv.     The cost and appropriate funding levels required to implement security controls.  iv.     セキュリティ管理を実施するために必要なコストと適切な資金レベル
ISN 2022/04 Annex B ISN 2022/04 附属書 B
NCSC Good Design Guidance  NCSCグッドデザインガイダンス 
1. The following should be considered during the capability design to ensure security compromise is made difficult:  1.セキュリティ侵害を困難にするため、ケイパビリティ設計時に以下を考慮する必要がある。
a.       Understand external input cannot be trusted;  a.       外部からの入力は信用できないことを理解する。
b.      Transform, validate, or render data input safely;  b.      入力されたデータを安全に変換、検証、またはレンダリングする。
c.       Reduce the attack surface;  c.       攻撃対象領域を縮小する。
d.      Identify and gain confidence in crucial security controls;  d.      重要なセキュリティ制御を特定し、信頼性を高める。
e.       Protect management and operations environments from targeted attacks;  e.       管理・運用環境を標的型攻撃から守る。
f.        Prefer tried and tested approaches;  f.        試行錯誤したアプローチを好む。
g.      Ensure all operations are individually authorised and accounted for;  g.      すべての業務が個別に承認され、説明されていることを確認する。
h.      Design for easy maintenance;  h.      メンテナンス性を考慮した設計。
i.        Make it easy for administrators to manage access control; and  i.        管理者によるアクセスコントロールの管理を容易にする。
j.        Make it easy for users to do the right thing.  j.        ユーザーが正しい行動をしやすいようにする。
2. The following should be considered to ensure the capabilities are able to adequately detect and report malicious behaviour:  2.悪意のある行動を適切に検知し報告する機能を確保するために、以下のことを考慮する必要がある。
a.       Collect all relevant security events and logs;  a.       関連するすべてのセキュリティイベントとログを収集する。
b.      Design simple communication flows between components;  b.      コンポーネント間の簡単な通信フローを設計する。
c.       Detect malware command and control communications;  c.       マルウェアのコマンド&コントロール通信を検出する。
d.      Make monitoring independent of the system being monitored;  d.      監視を監視対象システムから独立させる。
e.       Make it difficult for attackers to detect security rules through external testing; and  e.       攻撃者が外部テストによってセキュリティルールを検出することを困難にすること。
f.        Understand 'normal' and detect the abnormal.  f.        「正常」を理解し、「異常」を察知する。
3. To make disruption to the capability difficult, the following should be considered as part of the capability design.  3.ケイパビリティの崩壊を困難にするため、ケイパビリティ設計の一環として以下を考慮する必要がある。
a.       Ensure capabilities are resilient to both attack and failure;  a.       攻撃と故障の両方に対応できるケイパビリティを確保する。
b.      Design for scalability;  b.      スケーラビリティを考慮した設計。
c.       Identify bottlenecks, test for high load and denial of service conditions; and  c.       ボトルネックの特定、高負荷およびサービス拒否状態のテスト、および 
d.      Identify dependencies on third parties and plan for the failure of that third party.  d.      サードパーティーへの依存度を把握し、そのサードパーティーの障害に備えた計画を立てる。
4. To reduce the impact of compromise following a breach to the capability, the following should be considered:  4.ケイパビリティへの侵入後の侵害の影響を軽減するために、以下を考慮する必要がある。
a.       Use a zoned or segmented network approach;  a.       ゾーン化またはセグメント化されたネットワークアプローチを使用する。
b.      Remove unnecessary functionality, especially where unauthorised use would be damaging;  b.      不要な機能を削除する。特に、不正な使用で損害を与えるような場合は、不要な機能を削除する。
c.       Beware of creating a ‘management bypass’;  c.       経営者の迂闊な行動」を生み出さないように注意すること。
d.      Make it easy to recover following a compromise;  d.      妥協後の復旧を容易にする。
e.       Design to support 'separation of duties';  e.       職務の分離」を支援する設計。
f.        Anonymise data when it’s exported to reporting tools;  f.        レポートツールにエクスポートする際に、データを匿名化します。
g.      Don't allow arbitrary queries against your data; and  g.      データに対する任意のクエリーを許可しない。
h.      Avoid unnecessary caches of data.  h.      不必要なデータのキャッシュを避ける。
[1] MOD’s approach to Secure by Design is informed by industry good practice (from the National Cyber Security Centre’s Secure Design Principles), three lines of defence security assurance model and National Institute of Standards & Technology (NIST) Cyber Security Framework. [1]防衛省のセキュア・バイ・デザインへの取り組みは、業界の優れた実践例(National Cyber Security Centreのセキュアデザイン原則)、3つの防衛線セキュリティ保証モデル、米国標準技術局(NIST)のサイバーセキュリティフレームワークに基づくものである。
[2] Previously known as the Security Assurance Co-ordinator (SAC). [2]以前はSecurity Assurance Co-ordinator (SAC)と呼ばれていました。
[3] Previously known as the CyDR SACs and Accreditors and TLB Accreditor roles. [3]以前はCyDR SACs and AccreditorsとTLB Accreditorの役割として知られていました。
[4] this must include the security risk from supplier activities and the contractual arrangements. [4]これには、供給者の活動や契約上の取り決めから生じるセキュリティリスクも含まれなければならない。
[5] Where a focused threat assessment is required to develop the risks, the Capability Owner should be contacted for further support. [5] リスクを開発するために集中的な脅威の評価が必要な場合、ケイパビリティ所有者に連絡してさらなるサポートを受けるべきである。
[6] https://www.gov.uk/guidance/defence-cyber-protection-partnership. [6] https://www.gov.uk/guidance/defence-cyber-protection-partnership。

|

« 米国 GAO 消費者保護:議会は消費者ランク付けに使用されるスコアに関する保護の強化を検討すべき (2022.05.26) | Main | 米国 FBI サイバーセキュリティに関するボストン会議2022でのFBI長官の基調講演 »

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



« 米国 GAO 消費者保護:議会は消費者ランク付けに使用されるスコアに関する保護の強化を検討すべき (2022.05.26) | Main | 米国 FBI サイバーセキュリティに関するボストン会議2022でのFBI長官の基調講演 »