NIST SP 800-160 Vol.1 Rev.1 信頼性の高い安全なシステムのエンジニアリング (2022.11.16)
こんにちは、丸山満彦です。
NISTが意見募集をしていた、SP 800-160 Vol.1 Rev.1 信頼性の高い安全なシステムのエンジニアリングの最終版を公表していますね。。。
● NIST - ITL
・2022.11.16 SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems
SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems | SP 800-160 Vol.1 Rev.1 信頼性の高い安全なシステムのエンジニアリング |
Abstract | 概要 |
This publication describes a basis for establishing principles, concepts, activities, and tasks for engineering trustworthy secure systems. Such principles, concepts, activities, and tasks can be effectively applied within systems engineering efforts to foster a common mindset to deliver security for any system, regardless of the system’s purpose, type, scope, size, complexity, or the stage of its system life cycle. The intent of this publication is to advance systems engineering in developing trustworthy systems for contested operational environments (generally referred to as systems security engineering) and to serve as a basis for developing educational and training programs, professional certifications, and other assessment criteria. | 本書は、信頼性の高いセキュアなシステムを設計するための原則、概念、活動、およびタスクを確立するための基礎を説明するものである。このような原則、概念、活動、およびタスクは、システムの目的、種類、範囲、規模、複雑さ、またはシステムライフサイクルの段階に関係なく、あらゆるシステムのセキュリティを実現するための共通の考え方を醸成するために、システムエンジニアの取り組みに効果的に適用することができる。本書の目的は、厳しい運用環境において信頼性の高いシステムを開発するシステム工学(一般にシステムセキュリティ工学と呼ばれる)を発展させ、教育・訓練プログラム、専門家認定、その他の評価基準を開発するための基礎とすることである。 |
・[PDF] SP 800-160 Vol. 1 Rev. 1
目次...
1. Introduction | 1. はじめに |
1.1. Purpose and Applicability | 1.1. 目的及び適用性 |
1.2. Target Audience | 1.2. 対象読者 |
1.3. How to Use this Publication | 1.3. この出版物の使用方法 |
1.4. Organization of this Publication | 1.4. 本書の構成 |
2. Systems Engineering Overview | 2. システムエンジニアリングの概要 |
2.1. System Concepts | 2.1. システム概念 |
2.1.1. Systems and System Structure | 2.1.1. システムとシステム構造 |
2.1.2. Interfacing, Enabling, and Interoperating Systems | 2.1.2. システムのインターフェイス、イネーブル、および相互運用 |
2.2. Systems Engineering Foundations | 2.2. システムエンジニアリングの基礎 |
2.3. Trust and Trustworthiness | 2.3. 信頼と信用性 |
3. System Security Concepts | 3. システムセキュリティの概念 |
3.1. The Concept of Security | 3.1. セキュリティの概念 |
3.2. The Concept of an Adequately Secure System | 3.2. 十分な安全性を持つシステムの概念 |
3.3. Characteristics of Systems | 3.3. システムの特徴 |
3.4. The Concept of Assets | 3.4. 資産の概念 |
3.5. The Concepts of Loss and Loss Control | 3.5. 損失と損失管理の概念 |
3.6. Reasoning about Asset Loss | 3.6. 資産の損失に関する推論 |
3.7. Determining Protection Needs | 3.7. 保護の必要性の判断 |
3.8. System Security Viewpoints | 3.8. システムセキュリティの視点 |
3.9. Demonstrating System Security | 3.9. システムセキュリティの実証 |
3.10. Systems Security Engineering | 3.10. システムセキュリティエンジニアリング |
4. Systems Security Engineering Framework | 4. システムセキュリティ工学の枠組み |
4.1. The Problem Context | 4.1. 問題の背景 |
4.2. The Solution Context | 4.2. ソリューションコンテキスト |
4.3. The Trustworthiness Context | 4.3. 信頼性のコンテキスト |
References | 参考文献 |
Appendix A. Acronyms | 附属書A. 頭字語 |
Appendix B. Glossary | 附属書B. 用語集 |
Appendix C. Security Policy and Requirements | 附属書C. セキュリティポリシーと要求事項 |
C.1. Security Policy | C.1. セキュリティポリシー |
C.2. Security Requirements | C.2. セキュリティに関する要求事項 |
C.3. Distinguishing Requirements, Policy, and Mechanisms | C.3. 要求事項、ポリシー、メカニズムの区別 |
Appendix D. Trustworthy Secure Design | 附属書D. 信頼性の高いセキュアな設計 |
D.1. Design Approach for Trustworthy Systems | D.1. 信頼性の高いシステムのための設計アプローチ |
D.2.Design Considering Emergence | D.2. 創発性を考慮した設計 |
D.3. Security Design Order of Precedence | D.3. セキュリティ設計の優先順位 |
D.4. Functional Design Considerations | D.4. 機能的設計の考慮点 |
Appendix E. Principles for Trustworthy Secure Design | 附属書E. 信頼性の高いセキュアな設計のための原則 |
E.1. Anomaly Detection | E.1. 異常の検出 |
E.2. Clear Abstractions | E.2. 明確な抽象化 |
E.3. Commensurate Protection | E.3. 適切な保護 |
E.4. Commensurate Response | E.4. 正確な応答 |
E.5. Commensurate Rigor | E.5. 適正な厳しさ |
E.6. Commensurate Trustworthiness | E.6. 正確な信頼性 |
E.7. Compositional Trustworthiness | E.7. 構成的信頼性 |
E.8. Continuous Protection | E.8. 継続的な保護 |
E.9. Defense In Depth | E.9. 多重防御 |
E.10. Distributed Privilege | E.10. 特権の分散 |
E.11. Diversity (Dynamicity) | E.11. 多様性(動的) |
E.12. Domain Separation | E.12. ドメイン分離 |
E.13. Hierarchical Protection | E.13. 階層的な保護 |
E.14. Least Functionality | E.14. 最小限の機能 |
E.15. Least Persistence | E.15. 最小限の持続性 |
E.16. Least Privilege | E.16. 最小の特権 |
E.17. Least Sharing | E.17. 最小限の共有 |
E.18. Loss Margins | E.18. 損失マージン |
E.19. Mediated Access | E.19. 媒介アクセス |
E.20. Minimal Trusted Elements | E.20. 最小限の信頼される要素 |
E.21. Minimize Detectability | E.21. 検出可能性の最小化 |
E.22. Protective Defaults | E.22. 保護デフォルト |
E.23. Protective Failure | E.23. プロテクトの失敗 |
E.24. Protective Recovery | E.24. 保護リカバリ |
E.25. Reduced Complexity | E.25. 複雑さの軽減 |
E.26. Redundancy | E.26. 冗長性 |
E.27. Self-Reliant Trustworthiness | E.27. 自立した信頼性 |
E.28. Structured Decomposition and Composition | E.28. 構造化分解と構造化合成 |
E.29. Substantiated Trustworthiness | E.29. 裏付けされた信頼性の高さ |
E.30. Trustworthy System Control | E.30. 信頼性の高いシステム制御 |
Appendix F. Trustworthiness and Assurance | 附属書F.信頼性及び保証 |
F.1. Trust and Trustworthiness | F.1. 信頼と信用 |
F.2.Assurance | F.2.保証 |
Appendix G. System Life Cycle Processes Overview | 附属書G. システムライフサイクルプロセスの概要 |
G.1. Process Overview | G.1. プロセスの概要 |
G.2. Process Relationships | G.2. プロセスの関係 |
Appendix H. Technical Processes | 附属書H. 技術プロセス |
H.1. Business or Mission Analysis | H.1. ビジネスまたはミッションの分析 |
H.2. Stakeholder Needs and Requirements Definition | H.2. ステークホルダーのニーズと要件の定義 |
H.3. System Requirements Definition | H.3. システム要件定義 |
H.4. System Architecture Definition | H.4. システムアーキテクチャの定義 |
H.5. Design Definition | H.5. デザイン定義 |
H.6. System Analysis | H.6. システム分析 |
H.7. Implementation | H.7. 実装 |
H.8. Integration | H.8. 統合 |
H.9. Verification | H.9. 検証 |
H.10. Transition | H.10. 移行 |
H.11. Validation | H.11. 妥当性確認 |
H.12. Operation | H.12. 操作 |
H.13. Maintenance | H.13. 保守者ンス |
H.14. Disposal | H.14. 廃棄について |
Appendix I. Technical Management Processes | 附属書 I. 技術管理プロセス |
I.1. Project Planning | I.1. プロジェクト計画 |
I.2. Project Assessment and Control | I.2. プロジェクトの評価と管理 |
I.3. Decision Management | I.3. 意思決定管理 |
I.4. Risk Management | I.4. リスク管理 |
I.5. Configuration Management | I.5. コンフィギュレーション・マネジメント |
I.6. Information Management | I.6. 情報管理 |
I.7. Measurement | I.7. 測定 |
I.8. Quality Assurance | I.8. 品質保証 |
Appendix J. Organizational Project-Enabling Processes | 附属書J. プロジェクトを実現するための組織的プロセス |
J.1. Life Cycle Model Management | J.1. ライフサイクルモデルの管理 |
J.2. Infrastructure Management | J.2. インフラストラクチャー管理 |
J.3. Portfolio Management | J.3. ポートフォリオ管理 |
J.4. Human Resource Management | J.4. ヒューマンリソースマネジメント |
J.5. Quality Management | J.5. 品質管理 |
J.6. Knowledge Management | J.6. ナレッジマネジメント |
Appendix K. Agreement Processes | 附属書K. 契約プロセス |
K.1.Acquisition | K.1.取得 |
K.2. Supply | K.2. 供給 |
Appendix L. Change Log | 附属書 L. 変更履歴 |
1. Introduction | 1. はじめに |
Today’s systems[1] are inherently complex. The growth in the size, number, and types of components and technologies[2] that compose those systems as well as the system dependencies result in a range of consequences from inconvenience to catastrophic loss due to adversity[3] within the operating environment. Managing the complexity of trustworthy secure systems requires achieving the appropriate level of confidence in the feasibility, correctness-in-concept, philosophy, and design of a system to produce only the intended behaviors and outcomes. This provides the foundation to address stakeholder protection needs and security concerns with sufficient confidence that the system functions only as intended while subjected to different types of adversity and to realistically bound those expectations with respect to constraints and uncertainty. The failure to address complexity and security will leave the Nation susceptible to potentially serious, severe, or catastrophic consequences. | 今日のシステム[1]は本質的に複雑である。システムを構成する部品や技術[2] の規模、数、種類の増加や、システムの依存関係により、運用環境における不都合から逆境による壊滅的な損失[3]まで、様々な結果が生じている。信頼性の高い安全なシステムの複雑性を管理するには、意図された動作と結果のみをもたらすシステムの実現可能性、概念の正しさ、哲学、および設計について、適切なレベルの信頼性を達成することが必要である。これは、さまざまな種類の逆境にさらされてもシステムが意図したとおりにしか機能しないという十分な確信をもって、利害関係者の保護ニーズとセキュリティの懸念に対処し、制約と不確実性に関してそれらの期待を現実的に拘束するための基盤を提供するものである。複雑性と安全性に対処できなければ、国家は深刻な、深刻な、または破滅的な結果に陥る可能性がある。 |
The term security is used in this publication to mean freedom from the conditions that can cause a loss of assets with unacceptable consequences.[4] Stakeholders must define the scope of security in terms of the assets to which security applies and the consequences against which security is assessed.[5] Systems engineering provides a foundation for a disciplined and structured approach to building assured, trustworthy secure systems. As a systems engineering subdiscipline, systems security engineering addresses security-relevant considerations intended to produce secure outcomes. The engineering efforts are conducted at the appropriate level of fidelity and rigor needed to achieve trustworthiness and assurance objectives. | 本書では、セキュリティという用語は、許容できない結果を伴う資産の損失を引き起こす可能性のある条件からの自由を意味するものとして使用される[4] 。利害関係者は、セキュリティが適用される資産と、セキュリティを評価する結果という観点からセキュリティの範囲を定義しなければならない[5] 。システムズエンジニアリングの下位分野として、システムセキュリティ工学は、安全な結果をもたらすことを意図したセキュリティ関連の考慮事項に取り組む。工学的な取り組みは、信頼性と保証の目標を達成するために必要な、適切なレベルの忠実度と厳密さで実施される。 |
Peter Neumann described the concept of trustworthiness in [2] as follows: | ピーター・ノイマンは[2]で信頼性の概念を次のように説明している。 |
“By trustworthiness, we mean simply worthy of being trusted to fulfill whatever critical requirements may be needed for a particular component, subsystem, system, network, application, mission, enterprise, or other entity. Trustworthiness requirements might typically involve (for example) attributes of security, reliability, performance, and survivability under a wide range of potential adversities. Measures of trustworthiness are meaningful only to the extent that (a) the requirements are sufficiently complete and well defined, and (b) can be accurately evaluated.” | 「信頼性とは、特定のコンポーネント、サブシステム、システム、ネットワーク、アプリケーション、ミッション、エンタープライズ、または他のエンティティに必要とされるあらゆる重要な要件を満たすために信頼されるに値することを意味する。信頼性の要件には、例えば、セキュリティ、信頼性、性能、および広範な潜在的敵対行為下での生存性などの属性が含まれることが一般的である。信頼性の測定は、(a)要件が十分に完全で、よく定義され、(b)正確に評価できる範囲でのみ意味がある。 |
Systems security engineering provides complementary engineering capabilities that extend the concept of trustworthiness to deliver trustworthy secure systems. Trustworthiness is not only about demonstrably meeting a set of requirements. The requirements must also be complete, consistent, and correct. From a security perspective, a trustworthy system meets a set of welldefined requirements, including security requirements. Through evidence and expert judgment, trustworthy secure systems can limit and prevent the effects of modern adversities. Such adversities come in malicious and non-malicious forms and can emanate from a variety of sources, including physical and electronic. Adversities can include attacks from determined and capable adversaries, human errors of omission and commission, accidents and incidents, component faults and failures, abuses and misuses, and natural and human-made disasters. | システムセキュリティ工学は、信頼性の概念を拡張し、信頼性の高い安全なシステムを提供するための補完的な工学能力を提供する。信頼性とは、一連の要件を実証的に満たすことだけではない。要件は完全で、一貫性があり、正しくなければならない。セキュリティの観点からは、信頼性の高いシステムは、セキュリティ要件を含む、明確に定義された一連の要件を満たしている。証拠と専門家の判断により、信頼性の高い安全なシステムは、現代の敵の影響を制限し、防止することができる。このような敵は、悪意のあるものとないものがあり、物理的、電子的なものを含む様々なソースから発生する可能性がある。逆境には、決意のある有能な敵からの攻撃、人間の不注意や過失、事故や事件、部品の欠陥や故障、悪用や誤用、自然災害や人為的災害などがある。 |
“Security is embedded in systems. Rather than two engineering groups designing two systems, one intended to protect the other, systems engineering specifies and designs a single system with security embedded in the system and its components.” | 「セキュリティはシステムに組み込まれる。2つのエンジニアリンググループが2つのシステムを設計し、一方が他方を保護することを意図するのではなく、システムエンジニアリングは、システムとそのコンポーネントにセキュリティを組み込んだ単一のシステムを指定・設計するのである。 |
-- An Objective of Security in the Future of Systems Engineering [7] | -・システムズエンジニアリングの将来におけるセキュリティの目的[7]。 |
1.1. Purpose and Applicability | 1.1. 目的及び適用範囲 |
This publication is intended to: | 本書は、次のことを目的としている。 |
・Provide a basis for establishing a discipline for systems security engineering as part of systems engineering in terms of its principles, concepts, activities, and tasks | ・システムズセキュリティ工学を、その原則、概念、活動、及び作業の観点から、システムズ工学の一部として確立するための基礎を提供すること |
・Foster a common mindset to deliver security for any system, regardless of its purpose, type, scope, size, complexity, or stage of the system life cycle | ・目的、種類、範囲、規模、複雑さ、システムライフサイクルの段階に関係なく、あらゆるシステムのセキュリティを実現するための共通の考え方を醸成すること |
・Demonstrate how selected systems security engineering principles, concepts, activities, and tasks can be effectively applied to systems engineering activities | ・選択したシステムセキュリティ工学の原則,概念,活動,タスクを,どのようにシステムエンジニアリング活動に効果的に適用できるかを示すこと |
・Advance the field of systems security engineering as a discipline that can be applied and studied | ・システムセキュリティ工学を応用・研究可能な学問分野として発展させること |
・Serve as a basis for the development of educational and training programs, including individual certifications and other professional assessment criteria | ・個人認定資格やその他の専門的な評価基準を含む、教育・訓練プログラムの開発の基礎となるようにすること |
The considerations set forth in this publication are applicable to all federal systems other than those systems designated as national security systems as defined in 44 U.S.C., Section 3542.[6] These considerations have been broadly developed from a technical and technical management perspective to complement similar considerations for national security systems and may be used for such systems with the approval of federal officials who exercise policy authority over such systems. State, local, and tribal governments, as well as private sector entities, are encouraged to consider using the material in this publication, as appropriate. | 本書に記載されている考慮事項は、44 U.S.C. 第 3542 条に定義されている国家安全保障システムとして指定されているシステム以外のすべての連邦システムに適用される[6]。これらの考慮事項は、国家安全保障システムに対する同様の考慮事項を補完するために技術及び技術管理の観点から幅広く策定されており、当該システムに対する政策権限を有する連邦当局者の承認を得て当該システムに使用できるようになっている。州、地方、および部族政府は、民間部門と同様に、本書の資料の適切な利用を検討することが推奨される。 |
The applicability statement is not meant to limit the technical and management application of these considerations. That is, the security design principles, concepts, and techniques described in this publication are part of a trustworthy secure design approach as described in Appendix D and can be applied in any of the following cases: | 適用性の記述は、これらの考慮事項の技術的および管理的な適用を制限することを意図していない。すなわち、本書に記載されているセキュリティ設計の原則、概念、および技術は、附属書Dに記載されている信頼性の高い安全な設計手法の一部であり、以下のいずれの場合にも適用することが可能である。 |
・Development of a new capability or system | ・新しい能力またはシステムの開発 |
The engineering effort includes such activities as concept exploration, preliminary or applied research to refine the concepts and/or feasibility of technologies employed in a new system, and an assessment of alternative solutions. This effort is initiated during the concept and development stages of the system life cycle. | エンジニアリングの取り組みには、コンセプトの探求、新システムに採用される技術のコンセプト及び/又は実現可能性を洗練させるための予備又は応用研究、及び代替ソリューションの評価などの活動が含まれる。この作業は、システムライフサイクルのコンセプトと開発段階において開始される。 |
・Modification of an existing capability or system | ・既存の能力またはシステムの修正 |
- Reactive modifications to fielded systems: The engineering effort occurs in response to adversity that diminishes or prevents the system from achieving the design intent. This effort can occur during the production, utilization, or support stages of the system life cycle and may be performed concurrently with or independent of day-to-day system operations. | ・実戦配備されたシステムに対する反応的な修正。このエンジニアリング作業は、システムが設計意図を達成するのを減少させるか妨げるような逆境に対応して行われる。この作業は、システムライフサイクルの生産、利用、またはサポート段階において発生し、日常的なシステム運用と同時に行われることもあれば、独立に行われることもある。 |
- Planned upgrades to fielded systems while continuing to sustain day-to-day operations: Planned system upgrades may enhance an existing system capability, provide a new capability, or constitute a technology refresh of an existing capability. This effort occurs during the production, utilization, or support stages of the system life cycle. | ・日々の運用を維持しつつ、実戦配備されたシステムの計画的なアップグレード。計画されたシステムアップグレードは、既存のシステム能力を強化し、新しい能力を提供し、または既存の能力の技術更新を構成することができる。この作業は、システムライフサイクルの生産、利用、またはサポート段階において行われる。 |
- Planned upgrades to fielded systems that result in new systems: The engineering effort is conducted as if developing a new system with a system life cycle that is distinct from the life cycle of a fielded system. The upgrades are performed in a development environment that is independent of the fielded system. | ・新システムにつながる、実戦配備されたシステムの計画されたアップグレード。このエンジニアリング作業は、実戦配備されたシステムのライフサイクルとは異なるシステムライフサイクルを持つ新システムを開発するように実施される。アップグレードは、実戦配備されたシステムから独立した開発環境において実施される。 |
・Evolution of an existing capability or system | ・既存の能力またはシステムの進化 |
The engineering effort involves migrating or adapting a system or system implementation from one operational environment or set of operating conditions to another operational environment or set of operating conditions.[7] | システムまたはシステム実装を、ある運用環境または一連の運用条件から別の運用環境または一連の運用条件へ移行または適応させるエンジニアリングの作業である[7]。 |
・Retirement of an existing capability or system | ・既存の能力又はシステムの退役 |
The engineering effort removes system functions, services, elements, or the entire system from operation and may include the transition of system functions and services to another system. The effort occurs during the retirement stage of the system life cycle and may be conducted while sustaining day-to-day operations. | システム機能、サービス、要素、またはシステム全体を運用から外し、システム機能及びサービスを別のシステムへ移行することを含む場合がある。この作業は、システムライフサイクルの引退段階で行われ、日常的な運用を維持しながら実施されることもある。 |
・Development of a dedicated, domain-specific, or special-purpose capability or system | ・専用、ドメイン固有、または特殊な目的の能力またはシステムの開発 |
- Security-dedicated or security-purposed system: The engineering effort delivers a system that satisfies a security-dedicated need or provides a security-oriented purpose and does so as a stand-alone system that may monitor or interact with other systems. Such systems can include surveillance systems, physical protection systems, monitoring systems, and security service provisioning systems. | ・セキュリティ専用またはセキュリティ目的のシステム。セキュリティ専用のニーズを満たすか、またはセキュリティ指向の目的を提供するシステムであり、他のシステムを監視したり、他のシステムと相互作用することができる独立したシステムとして行うエンジニアリング作業。このようなシステムには、監視システム、物理的保護システム、監視システム、及びセキュリティサービス提供システムが含まれることがある。 |
- High-confidence, dedicated-purpose system: The engineering effort delivers a system that satisfies the need for real-time vehicular control, industrial or utility processes, weapons, nuclear power plants, and other special-purpose needs. Such systems may include multiple operational states or modes with varying forms of manual, semi-manual, automated, or autonomous modes. These systems have highly deterministic properties, strict timing constraints, functional interlocks, and severe or catastrophic consequences of failure. | ・信頼性の高い、専用目的のシステム。リアルタイム車両制御、産業用または公益事業用プロセス、兵器、原子力発電所、およびその他の特別な目的のニーズを満たすシステムを提供するエンジニアリング作業である。このようなシステムには、手動、半手動、自動、または自律モードなど、さまざまな形態の複数の動作状態またはモードが含まれる場合がある。これらのシステムは、高度に決定論的な特性、厳格なタイミング制約、機能的インターロック、および故障の深刻なまたは壊滅的な結果を有する。 |
・Development of a system of systems | ・システム・オブ・システムの開発 |
The engineering effort occurs across a set of constituent systems, each with its own stakeholders, primary purpose, and planned evolution. The composition of the constituent systems into a system of systems as noted in [9] produces a capability that would otherwise be difficult or impractical to achieve. This effort can occur across a variety of system of systems from a relatively informal, unplanned system of systems concept and evolution that emerges over time via voluntary participation to a more formal execution with the most formal being a system of systems concept that is directed, structured, planned, and achieved via a centrally managed engineering effort. Any resulting emergent behavior often introduces opportunities and additional challenges for systems security engineering. | エンジニアリング作業は、それぞれが利害関係者、主要目的、および計画された進化を持つ一連の構成システムにわたって行われる。[9]で述べたように、構成システムをシステムオブシステムとして構成することで、他の方法では実現が困難または非現実的な能力が生み出される。この努力は、自発的な参加によって時間をかけて出現する比較的非公式で無計画なシステムコンセプトと進化から、最も正式なシステムコンセプトは、中央管理のエンジニアリング努力によって指示、構造化、計画、達成されるシステムオブシステムであり、より正式な実行まで、様々なシステムオブシステムで起こりうるものである。その結果生じるいかなる創発的行動も、しばしばシステムセキュリティ工学に機会と新たな課題をもたらす。 |
1.2. Target Audience | 1.2. 対象読者 |
This publication is intended for systems engineers, security engineers, and other engineering professionals. The term systems security engineer is used to include systems engineers and security professionals who apply the concepts and principles and perform the activities and tasks described in this publication.[8] This publication can also be used by professionals who perform other system life cycle activities or tasks, including: | 本書は、システムエンジニア、セキュリティエンジニア、およびその他のエンジニアリング専門家を対象としている。システムセキュリティエンジニアという用語は、本書に記載された概念と原則を適用し、活動とタスクを実行するシステムエンジニアとセキュリティ専門家を含む意味で使用される[8]。 本書は、以下のような他のシステムライフサイクル活動またはタスクを実行する専門家も使用することができる。 |
・Individuals with security governance, risk management, and oversight responsibilities | ・セキュリティガバナンス、リスク管理、および監視の責任を有する者 |
・Individuals with security verification, validation, testing, evaluation, auditing, assessment, inspection, and monitoring responsibilities | ・セキュリティの検証、妥当性確認、テスト、評価、監査、評価、検査、及び、監視を担当する個人 |
・Individuals with acquisition, budgeting, and project management responsibilities | ・取得、予算、及びプロジェクト管理の責任を有する個人 |
・Individuals with operations, maintenance, sustainment, logistics, and support responsibilities | ・運用、保守、維持、ロジスティクス、サポートに責任を持つ個人 |
・Providers of technology-related products, systems, or services | ・技術関連製品、システム、またはサービスのプロバイダー |
・Educators in academic institutions that offer systems engineering, computer engineering, computer science, software engineering, and computer security programs | ・システムエンジニアリング、コンピュータエンジニアリング、コンピュータサイエンス、ソフトウェアエンジニアリング、コンピュータセキュリティプログラムを提供する学術機関の教育者 |
1.3. How to Use this Publication | 1.3. 本書の使用方法 |
This publication is intended to serve as a reference and educational resource for systems engineers, engineering specialties, architects, designers, and any individuals involved in the development of trustworthy secure systems and system components. It is meant to be flexible in its application to meet the diverse needs of organizations. There is no expectation that all of the technical content in this publication will be used as part of a systems engineering effort. Rather, the concepts and principles for trustworthy secure design in Appendices D through F as well as the systems life cycle processes and security-relevant activities and tasks in Appendices G through K can be selectively employed by organizations – relying on the experience and expertise of the engineering teams to determine what is correct for their purposes. Applying the content of this publication enables the achievement of security outcomes that are consistent with the systems engineering perspective on system life cycle processes. | 本書は、システムエンジニア、専門技術者、建築家、設計者、および信頼性の高いセキュアシステムとシステムコンポーネントの開発に携わるすべての人のための参考および教育リソースとして機能することを意図している。本書は、組織の多様なニーズに対応するために柔軟に適用されることを意図している。本書の技術的内容のすべてが、システムエンジニアリングの一環として使用されることを期待するものではない。むしろ、附属書D〜Fの信頼性の高い安全設計のための概念と原則、および附属書G〜Kのシステムライフサイクルプロセスとセキュリティ関連の活動やタスクは、組織が選択的に採用できるものである。本書の内容を適用することで、システムライフサイクルプロセスに関するシステム工学の視点と一致するセキュリ ティ成果を達成することができる。 |
The system life cycle processes described in this publication can take advantage of any system or software development methodology. The processes are equally applicable to waterfall, spiral, DevOps, agile, and other approaches. The processes can be applied recursively, iteratively, concurrently, sequentially, or in parallel and to any system regardless of its size, complexity, purpose, scope, operational environment, or special nature. The full extent of the application of the content in this publication is guided by stakeholder capability needs, protection needs, and concerns with particular attention paid to considerations of cost, schedule, and performance. | 本書で説明するシステムライフサイクルプロセスは、あらゆるシステムまたはソフトウェア開発手法を活用することができる。このプロセスは、ウォーターフォール、スパイラル、DevOps、アジャイル、その他のアプローチにも同様に適用可能である。プロセスは、再帰的、反復的、同時進行、順次、または並行して、その規模、複雑さ、目的、範囲、運用環境、または特殊性にかかわらず、あらゆるシステムに適用することができる。本書の内容をどの程度適用するかは、利害関係者の能力ニーズ、保護ニーズ、およびコスト、スケジュール、性能の考慮事項に特に注意を払いながら決定される。 |
1.4. Organization of this Publication | 1.4. 本書の構成 |
The remainder of this publication is organized as follows: | 本書の構成は以下の通りである。 |
・Chapter 2 presents an overview of systems engineering and the fundamental concepts associated with engineering trustworthy secure systems. This includes basic concepts that address the structure and types of systems, systems engineering foundations, and the concepts of trust and trustworthiness of systems and system components. | ・第2章では、システムズエンジニアリングの概要と、信頼性の高い安全なシステムのエンジニアリングに関連する基本的な概念 を示す。これには、システムの構造と種類、システム工学の基礎、システム及びシステム構成要素の信頼と信頼性の概念に対応する基本的な概念が含まれる。 |
・Chapter 3 describes foundational system security concepts and an engineering perspective to building trustworthy secure systems. This includes the concepts of security and system security, the nature and character of systems, the concepts of assets and asset loss, reasoning about asset loss, defining protection needs, system security viewpoints, demonstrating system security, and an introduction to systems security engineering. | ・第3章では、システムセキュリティの基礎的な概念と、信頼性の高い安全なシステムを構築するための工学的な視点について説明する。これには、セキュリティとシステムセキュリティの概念、システムの性質と特徴、資産と資産損失の概念、資産損失の推論、保護ニーズの定義、システムセキュリティの視点、システムセキュリティの実証、システムセキュリティ工学の紹介が含まれる。 |
・Chapter 4 provides a systems security engineering framework that includes a problem context, solution context, and trustworthiness context. | ・第4章では、問題の背景、解決策の背景、信頼性の背景を含む、システムセキュリティ工学の枠組みを提供している。 |
The following sections provide additional information to support the engineering of trustworthy secure systems: | 以下の章では、信頼性の高い安全なシステムの設計を支援するための追加情報を提供する。 |
・References | ・参考文献 |
・Appendix A: Glossary | ・附属書A: 用語集 |
・Appendix B: Acronyms | ・附属書B: 頭字語 |
・Appendix C: Security Policy and Requirements | ・附属書C: セキュリティポリシーと要求事項 |
・Appendix D: Trustworthy Secure Design | ・附属書D: 信頼性の高いセキュアな設計 |
・Appendix E: Principles for Trustworthy Secure Design | ・附属書E: 信頼性の高いセキュアな設計のための原則 |
・Appendix F: Trustworthiness and Assurance | ・附属書F: 信頼性と保証 |
・Appendix G: System Life Cycle Processes Overview | ・附属書G: システムライフサイクルプロセスの概要 |
・Appendix H: Technical Processes | ・附属書H: 技術プロセス |
・Appendix I: Technical Management Processes | ・附属書I: 技術管理プロセス |
・Appendix J: Organizational Project-Enabling Processes | ・附属書J: プロジェクトを実現するための組織的プロセス |
・Appendix K: Agreement Processes | ・附属書K: 契約プロセス |
・Appendix L: Change Log | ・附属書L: 変更履歴 |
ENGINEERING-DRIVEN SOLUTIONS | エンジニアリング主導のソリューション |
The effectiveness of any engineering discipline first requires a thorough understanding of the problem and consideration of all feasible solutions before acting to solve the identified problem. To maximize the effectiveness of systems security engineering, the security requirements for the protection against asset loss must be driven by business, mission, and all other stakeholder asset loss concerns. The security requirements are defined and managed as a well-defined set of engineering requirements and cannot be addressed independently or after the fact. | どのようなエンジニアリング分野でも、その有効性を高めるには、まず問題を徹底的に理解し、特定された問題を解決するために行動する前に、実現可能なすべての解決策を検討することが必要である。システムセキュリティエンジニアリングの効果を最大にするためには、資産損失から保護するためのセキュリティ要件が、ビジネス、ミッション、その他すべての利害関係者の資産損失に関する懸念によって推進される必要がある。セキュリティ要件は、明確に定義されたエンジニアリング要件のセットとして管理され、独立して、あるいは事後的に対処することはできない。 |
In the context of systems security engineering, the term protection has a broad scope and is primarily focused on the concept of assets and asset loss resulting in unacceptable consequences. The protection capability provided by a system goes beyond prevention and aims to control the events, conditions, and consequences that constitute asset loss. It is achieved in the form of the specific capability and constraints on system architecture, design, function, implementation, construction, selection of technology, methods, and tools and must be “engineered in” as part of the system life cycle process. | システムセキュリティ工学の文脈では、保護という用語は広い範囲を持ち、主に資産と許容できない結果をもたらす資産損失の概念に焦点が当てられている。システムが提供する保護機能は、予防を超え、資産損失を構成する事象、条件、結果を制御することを目的としている。それは、システムのアーキテクチャ、設計、機能、実装、構築、技術の選択、方法、ツールに関する特定の能力及び制約という形で達成され、システムのライフサイクルプロセスの一部として「組み込まれる」必要がある。 |
Understanding stakeholder asset protection needs (including assets that they own and assets that they do not own but must protect) and expressing those needs through a set of well-defined security requirements is an investment in the organization’s mission and business success in the modern age of global commerce, powerful computing systems, and network connectivity. | 利害関係者の資産保護ニーズ(所有する資産と所有しないが保護すべき資産を含む)を理解し、明確に定義された一連のセキュリティ要件を通じてそのニーズを表現することは、グローバルな商取引、強力なコンピュータシステム、ネットワーク接続の現代において、組織のミッションとビジネスの成功への投資である。 |
[1] A system is an arrangement of parts or elements that exhibit a behavior or meaning that the individual constituents do not [3]. The elements that compose a system include hardware, software, data, humans, processes, procedures, facilities, materials, and naturally occurring entities [4]. | [1] システムとは、個々の構成要素にはない動作や意味を示す部品や要素の配置のことである [3]。システムを構成する要素には、ハードウェア、ソフトウェア、データ、人間、プロセス、手順、施設、材料、自然発生的なエンティティが含まれる[4]。 |
[2] The term technology is used in the broadest context in this publication to include computing, communications, and information technologies, as well as any mechanical, hydraulic, pneumatic, or structural components in systems that contain or are enabled by such technologies. This view of technology provides an increased recognition of the digital, computational, and electronic machine-based foundation of modern complex systems and the growing importance of an assured trustworthiness of that foundation in providing the system’s functional capability and interaction with its physical machine and human system elements. | [2] 本書では、コンピュータ、通信、情報技術に加え、機械、油圧、空圧、構造物など、これらの技術を含む、またはこれらの技術によって実現されるシステムを含む広い意味で技術という用語を使用する。このような技術の見方は、現代の複雑なシステムのデジタル、計算及び電子機械ベースの基盤、並びにシステムの機能的能力及び物理的機械及び人間のシステム要素との相互作用を提供する上で、その基盤の確実な信頼性の重要性が増していることを認識させるものである。 |
[3] The term adversity refers to those conditions that can cause asset loss (e.g., threats, attacks, vulnerabilities, hazards, disruptions, and exposures). | [3] adversityという用語は、資産の損失を引き起こす可能性のある条件(例えば、脅威、攻撃、脆弱性、ハザード、混乱、露出など)を指す。 |
[4] The phrasing used in this definition of security is intentional. Ross Anderson noted in [5] that “now that everything’s acquiring connectivity, you can’t have safety without security, and these ecosystems are emerging.” Reflecting on this observation, the security definition was chosen to achieve alignment with a prevailing safety definition. | [4] このセキュリティの定義で使われている言い回しは意図的なものである。ロス・アンダーソンは[5]で、"あらゆるものが接続性を獲得している今、セキュリティなしに安全を得ることはできず、これらの生態系が出現している "と指摘している。この観察を反映し、セキュリティの定義は、一般的な安全の定義との整合性を達成するために選択された。 |
[5] Adapted from [6]. | [5] [6]より引用。 |
[6] Increasing the trustworthiness of systems is a significant undertaking that requires a substantial investment in the requirements, architecture, design, and development of systems, system components, applications, and networks. The policy in [8] requires federal agencies to implement the systems security engineering principles, concepts, techniques, and system life cycle processes in this publication for all high-value assets. | [6] システムの信頼性を高めることは、システム、システムコンポーネント、アプリケーション、及びネットワークの要件、アーキテクチャ、設計、及び開発に多大な投資を必要とする重要な事業である。[8]の方針は、連邦政府機関に対し、すべての高価値資産に対し、本書のシステムセキュリティ工学の原則、概念、技術、およびシステムライフサイクルプロセスを実施することを求めている。 |
[7] There is a growing need to reuse or leverage system implementation successes within operational environments that are different from how they were originally designed and developed. This type of reuse or reimplementation of systems within other operational environments is more efficient and represents potential advantages in maximizing interoperability between various system implementations. It should be noted that reuse may violate the assumptions used to determine that a system or system component was trustworthy. | [7] 当初の設計・開発方法とは異なる運用環境において、システム実装の成功事例を再利用または活用する必要性が高まっている。このような再利用や他の運用環境でのシステムの再実装は、より効率的であり、様々なシステム実装間の相互運用性を最大化する上で潜在的な利点を示すものである。再利用は、システムまたはシステムコンポーネントが信頼性の高いと判断するために使用された仮定に違反する可能性があることに留意すべきである。 |
[8] Systems security engineering activities and tasks can be applied to a mechanism, component, system element, system, system of systems, processes, or organizations. Regardless of the size or complexity of the entity, a transdisciplinary systems engineering team is needed to deliver systems that are trustworthy and that satisfy the protection needs and concerns of stakeholders. The processes are intended to be tailored to facilitate effectiveness. | [8] システムセキュリティ工学の活動及び作業は、メカニズム、コンポーネント、システム要素、システム、システムシステム、プロセス、または組織に適用することができる。事業体の規模や複雑さに関係なく、信頼性が高く、利害関係者の保護ニーズと懸念を満たすシステムを提供するためには、学際的なシステムエンジニアリングチームが必要である。このプロセスは、有効性を促進するために調整されることを意図している。 |
● まるちゃんの情報セキュリティ気まぐれ日記
・2022.01.21 NIST SP 800-160 Vol.1 Rev.1 (ドラフト) 信頼性の高いセキュアなシステムの構築 at 2022.01.11
« NIST SP 800-188(ドラフト)政府データセットの非識別化(ドラフト第3版)(2022.11.15) | Main | 経済産業省 日本発の自動運転システムの「シナリオに基づく安全性評価フレームワーク」に関する国際標準 (ISO34502) が発行されたことを公表 »
Comments