 | INTERNATIONAL TELECOMMUNICATION UNION TELECOMMUNICATION STUDY PERIOD 2025–2028 | SG 17-C3000 |
|---|---|---|
STUDY GROUP 17 | ||
Original: English | ||
| Question(s): | 1/17 | TODO-PLACE, 01 Feb 2025/02 Feb 2025 |
| CONTRIBUTION | ||
| Source: | Broadcom Europe Ltd. | |
| Title: | Design Principles and Best Practices for Security Architectures | |
| Contact: | Arnaud Taddei Broadcom Europe Ltd. United Kingdom | Tel. +41795061129 E-mail Arnaud.Taddei@broadcom.com |
| Contact: | Tel. | |
Introduction
This contribution provides a new proposed revised baseline text for X.arch-design. It took into consideration all the former editor notes and recognized a particular big obstacle in e.g. the need to define Zero Trust as an ITU-T wide definition.
1. Proposal
It is proposed that Q1 reviews this contribution, discussed it and agrees how to progress X.arch-design baseline text.
EDITORIAL NOTE
(Former editors notes below)
This document contains the revised baseline text for X.arch-design based on C821 with no change
These editors notes are now regrouped from 3 sources
The initial editors notes from C821
All the contribution C801 as a block
And one key remark during Q1 meeting that to resolve the issue paused by Zero Trust definition, it is proposed to use the language: "working definition for the purpose of this definition/recommendation"
Editors note the good compatibility of all of these contributions with no clashes and therefore will execute step by step all the proposals as there is not enough time in this SG17 meeting to do a good quality-controlled job
Editors note too that this above work will require a non-neglectable amount of time.
All editors notes from C821 and C803 kept verbatim for further execution below:
Summary Inputs:
This contribution provides some inputs for making the X.arch-design crisper and more coherent with other related documents under development in SG17 and specifically in SG 17/Q1. The baseline Text has NOT been edited or modified to enable the editors to undertake this exercise in their own structure based on their acceptance of the inputs.
The Proposed Title for the recommendation: X.arch-design: Security Design Principles and Concepts
The Recommendation should focus on primarily Two aspects of Security — Concepts & Principles.
The security concepts and principles laid out in this recommendation should be targeted to become the foundational cornerstones for all other Security related collaterals within SG 17/Q1 and even all other Questions in SG 17 or any other SG…
The security concepts and principles when applied to different stakeholders, application domains and use cases in Digital Systems, Solutions, Networks & Infrastructures shall enable insights to capture respective Security Concerns.
The captured Security Concerns shall enable developing the relevant Architecture Models, Views and Viewpoints.
A comprehensive collection of Security Concerns and their respective Architecture Models, Views & Viewpoints shall enable composing the wholistic Cyber Security Reference Architecture.
It is proposed that this recommendation along with TR.cs-uc, TR.cs-sc and X.cs-ra should be comprehensively coherent and complementary among themselves and there should be NO overlapping of same information.
As already acknowledged, it shall be appropriate to allocate the extra content to the relevant document(s) under development.
The graphics below illustrates the most optimum relationship and coherence amongst all the documents under development in SG 17/Q1.
Figure 1 — Relationship amongst SG 17/Q1 deliverables
A few key security Principles are submitted for consideration of the editors for inclusion with appropriate context:
Key Security Principles
Security characteristics must be considered holistically.
A culture of Security is essential to achieving Security.
Applicability of t Security to any entity — Security can be defined, verified, validated, and demonstrated for an entity.
Security is contexts-dependent — Security of an entity depends on its environment(s) and context of use. Understanding context is necessary for making Security trade-offs.
Security should apply risk management — It should be possible to define, validate and verify the level of trust required for a specific system by using a risk management approach (e.g. ISO/IEC 31000). Security risks and requirements are addressed using Security Controls.
Appropriate investment for Security — The costs of applying Security Controls and performing verification measurements should be commensurate with the unmitigated risk impacts cost.
Security should be required — Security risks and requirements should be identified, defined, analyzed, and evaluated for each Security characteristics and for every stage of the entity's life cycle.
Security must be managed throughout the entire system lifecycle.
Security shall be demonstrable — The trusted entity auditing process makes use of the measurable, verifiable, and demonstrable evidence. Assurance based on evidence is essential to establish Security. Assurance requires a systems viewpoint with evidence of multiple factors.
Security shall be transparent — The environments and contexts, Security characteristics, processes, stakeholders, information, risks, controls, outcomes, and evidence related to a declaration of Security in an entity shall be clearly defined, approved by stakeholders, and communicated.
Introduction
Since the last SG17 meeting a lot of team work and background work was performed between several SG17 members that lead to a context that had to be taken into account for this Contribution.
Indeed:
the initialisation and development of the work in X.cs-ra,
the welcome new work item proposal C583,
the Broadcom proposal for a CRAMM Roadmap internal SG17 document as per C652,
the outcome and the future of CG-SECAPA,
the fact that some work items in the incubation queue of Q15 may be claimed by Q1,
is creating a context that led the contribution to decide to purge any aspect which is on developing reference architectures and methodology from this document in order to limit the contour of this contribution to solely on:
What are the design security principles and associated that can constitute an inventory of use for the architect/design for when preparing a reference architecture, a solution architecture or an implementation.
This will give the opportunity for a better delineation and focus of this document back to its origin but now helped by a bigger context and will allow this document to reuse results from other works if necessary rather than defining terminology outside of its scope.
The future CRAMM Roadmap may actually consider if the section on the Architect/Designer shall stay in X.arch-design or should be moved into a more wholistic document listing all the stakeholders that participate to a Reference Architecture, yet, acknowledging that the Architect/Designer is a central one.
Therefore this contribution is progressing the work on X.arch-design in the following ways:
Remove the methodological section 8
The methodology should not be defined in this Recommendation.
Removal of most ISO and IEC references and terminology
Most of ISO and IEC references are useful but for methodology and more for X.cs-ra and other documents. Some key elements were kept.
The contributor is wondering if, as part of this nascent new series, a document regrouping all the references, terminology, etc. shouldn't be developed as a common denominator to avoid having to carry references and increase disalignment as much as the work is progressing.
Introduce a new section 6.2
The goal of this section is to give a reminder of what is done in other works to give a context and anchor the different work items. It may be tuned and refined in the future but the most important is that it shows that this Recommendation focuses on the point 3) mostly. This gives a clearer 'interface' between work items.
Regroup all the terms 'defined here' in the right place
This is in accordance to the document, yet a number of issues need to be considered:
it is surprising to the editors that a number of these terms do not seem to be defined anywhere and more research is needed in databases and other SDOs,
a number of interpretations need to be researched,
keep investigating the right SG17 series of Recommendations and in particular SDL,
a number of terms may need to be defined in other current and future Recommendations and may need to be removed from this document.
Make a convention section:
this is to create labels and identifiers for normative references and easier identification and use by the users of this Recommendation.
Developed of a number of principles
principle of least privilege,
principle of Zero Trust,
Others
the reference to RFC9413 is extremely relevant as illustrative of the complexity and wisdom that an architect/designer will need to exercise and was placed as an example in 6.3,
the important remark on 'Despite the fact that security of some elements in the system can be proved, there is no definite way to measure and compare security of the whole system' is now included and helps to define the critical 'Juvenal' security design constraint that the contributor failed to find a good way to introduce it, now done,
To be done (as to not forget a number of useful considerations)
keep developing all the sections,
position Confidentiality, Integrity, Availability somewhere,
confront this work with X.800,
clarify 'cyber security' vs 'cybersecurity'. The focus is on security of the entity of interest which may not be just a 'cyber' entity of interest and it provides a much more powerful context when 'security' is taken from the perspective of a design characteristic vs others and in particular vs the 'dependability' and later 'resiliency work',
is 'entity of interest' not a definition?
re-read the CISA TIC document and extract the 'capabilities' that are in fact principles,
rework completely section 8 on architect/designer and before anything discuss if it should stay in this Recommendation or if a new work item should be proposed to regroup the definitions of all the stakeholders in which the architect and the designer are central but not alone,
add about 'beyond corp' and then 'Jericho forum',
consider the concept of 'architecture building block ABB' from the opengroup and see their ZT architecture document (see in CG-SECAPA),
consider developing this one with metanorma and under GitHub. That would ease significantly maintaining the list of principles in proper tables, cross references, etc. and avoid mistakes.
The following todo list is kept here from the editorial notes of the current baseline text for the record
In this contribution:
a few minor editorial notes were introduced,
Confidentiality, Integrity and Availability are not security design principles, they are security properties,
There are no definitions for the term 'security properties' in the ITU terms and definitions database. Security properties could be interpreted as an architectural characteristic and as per CG-SECAPA work should not be positioned in this Recommendation,
X.800 is being re-studied and X.800 makes sense vs X.200,
It is necessary to reanalyse X.800 vs this Recommendation and identify concepts and security design principles if any though it is likely that X.800 will probably be a better input in the architecture parts of CRAMM as per CG-SECAPA,
the definition of Zero Trust was further developed but it shows a lot of issues:
The initial Forrester document from 2010 couldn't be found on internet at this stage and seems super-seeded by many newer documents that have a paywall
The NIST definition doesn't seem to be a definition as per ITU-T authors guide annex B.3.2 and so DEF01 is kept as-is,
The variations of Zero Trust semantic are absolutely huge making it very difficult to capture any alternatives for the reader,
Need to introduce a MECE approach
Observe that X.ztmc will have similar issues
BeyondCorp main documents were identified down to 2014 but not down to 2009,
CG-SECAPA focus on CRAMM shows a number of issues about this contribution that need to be discussed
Proposal
there is a critical need to have a work shop on the topic with all concerned experts as there are some clear issues to identify and define a number of foundational terms.