Notice

Copyright © TM Forum 2020. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by TM FORUM or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Direct inquiries to the TM Forum office:

181 New Road, Suite 304
Parsippany, NJ 07054 USA
Tel No. +1 973 944 5100
Fax No. +1 973 998 7916
TM Forum Web Page: www.tmforum.org

Executive Summary

Model Driven Development (MDD) has proven to be most useful for the development of standard business software applications. The Functional Architecture of the Open Digital Architecture is a standard for refactoring legacy BSS/OSS for digital business and cloud-native environment. Based on the five functional blocks defined in the functional architecture (versus the 2 in legacy BSS/OSS), demanding requirements in business technology applications, such as reusability, adaptability, flexibility, robustness and security are becoming increasingly part to evaluate the functionality of a software applications.  

The purpose of this guide is to standardize the modeling of Security, Privacy, Integrity and Trust directly into design and implementation of ODA objects - Components, environment and data (at rest, in transit). 
While methodologies such as threat modeling can be used to help obtain this understanding from a component and/or environment's design, it can be difficult to accurately map this understanding to an implementation. This difficulty suggests that there is a need for a technique that can be used to gain a better understanding of the trust boundaries that exist within an ODA implementation.

This introductory guide establishes a methodology to enable the mapping of security, privacy, integrity and trust requirements to an ODA component, environment and data handled. It is to foster the embedding of Secure-by-design, Privacy-Assurance as core tenets of ODA implementation.  Security and Privacy, which is a main concern in this guide, has usually been deferred to platform level solutions, e.g. by configuring roles. While this can sometimes meet near-sighted needs, it is not sufficient, can lead to high complexity in security policies implementation, and impair enforcement. The non-functional impact of this approach has the tendency of inhibiting performance, and breaking reusability of components. 

Component reusability is highest when both the functional and the non-functional requirements match. The modern software world has adopted the use of middleware platforms as a means to meet demanding requirements like adaptability, flexibility, robustness and security. This model-driven security and privacy framework is hereby offered as a living model to enable harness tested best models and practices to effectively assure ODA concepts are realizable from design to implementation and operations.  

1. Introduction

Security across BSS and OSS is receiving closer attention as the use of diverse data in business and operations grows exponentially. The majority of the security problems encountered have been as a result of poor design practices, where important security functionality has not been properly integrated as part of the design. Increasing value garnered from data availability and data access have become key objectives of selecting the optimal method to handling/treating security concerns like identity and access management. E.g. When is coarse-grain and/or fine-grain access control adequate to address needs in tandem with performance and core business objectives. These objectives are also driven by implications on operating policies, information system environment and regulatory regimes that have an implication on business concerns for overall security and privacy.

A critical aspect of any security and privacy review is the modeling of trust boundaries. This knowledge allows an audit to understand domains of trust or the lack of it, and how they influence one another. Without modeling this knowledge, an audit is generally not able to easily identify and mitigate against risks. As such, trust boundaries play an important role in effectively characterizing threats that exist, and also facilitate implementing appropriate controls to address both functional and non-functional needs of an information systems operation.

1.1. Scope

Security and privacy protection are critical to the service industry, and particularly to service providers across the industry. Capturing and modeling security and privacy requirements in the early stages of system development is essential to provide reliability and manageability assurance of security and privacy for both stakeholders and customers. "Security-by-design" and "Privacy-by-design" have become essential for digital-native businesses and thus the shift from "add it later", to including the requirements thereof as part of the design is mandatory for business assurance.

The guide takes an approach that uses first identifies and builds a repository for Security, Privacy, Trust and Integrity ontologies for domain specific semantics of models. This will target identifying the common semantics where Security, Privacy and Trust/Integrity specific properties can be embedded into design, development and operations. Thus, to agree on a common language reference to describe in ODA security and privacy meta models will enable understand and model the semantics using a meta model correlated to the ontology.

The confluence between Security and Privacy concepts have functional and non-functional implications on ODA Information Systems. Implementation, runtime and operations stages are no more linear models. DevOps models will now need to factor in Security which needs a model-driven approach to effectively address privacy and security targets.

1.2. Objectives

The objective of this guide is to ensure that ODA-compliant information systems are implemented with reduced security and privacy problems. It is also possible that this guide will enable triaging risks, impact and controls in a way that facilitates timely remediation in an easy and agile way.

The approach taken to formulating this guide, proposes the use of expressive UML-based approaches to construct and transform security - and privacy - design and operating concerns into models which apply model-driven architecting approach to generate technical implementation requirement in an automated way.

2. ODA Concerns for Security & Privacy Metamodel Development

The Security and Privacy Metamodel development leverages prior work done at NIST, W3C, CNCF and other reputable organizations to derive applicability of best practices based on the intent established by TM Forum members as requirement for ODA Security-by-design and Privacy-by-design. The ability therefore to be able to describe Security and Privacy needs for the different parts of ODA Functions, ODA Components, ODA Environments etc. in a way that addresses functional and non-functional requirements, while meeting digital business needs and ecosystem play, is a key concern.

Risk is the primary concern for both Security and Privacy, and it is modeled as a multiplier effect of Vulnerability, Threat and Impact. To effectively address risk concerns, context in the case of an ODA object, use case and environment must be well-defined. Context must also address the circumstances of the collection, generation, processing, disclosure and retention of data/information and the operations needed to maintain their life-cycle.

In establishing context for this guide, focus is on the ODA Component and ODA Environment regarding the various trust domains. Some general concerns and implications regarding both privacy and security are captured as assumptions in order to enable set the agenda for modeling and validating Security - and Privacy - requirements.

The guide will continue to capture concerns as they emerge, and factor them into standard language with their inter-relationships on an ongoing basis.

Generalized HL ODA Security and Privacy Implication to a Business

2.1. Security

2.2. Privacy and Confidentiality

Privacy is assured if the purpose relating to the use of the data, the visibility that refers to who is allowed to access, the granularity that describes how detailed the information is and the retention that corresponds to the period of data storage are all clearly communicated and fully revealed to the data owners as part of the execution of the governance around the data.

2.3. Integrity and Trust

Increasingly developing trustworthy software systems is a challenge as trustworthiness depends on trust relationships that are usually "assumed" and not adequately analyzed during the conceptualization and design of systems. Appropriate analysis of trust relationships and trust boundaries, and the appropriate justification of relevant trust assumptions, can result in systems that are designed to survive failure.

The meta-model for trust allows designer and developers to capture a comprehensive view on trust scenarios and incorporate them into the core principles of ODA. The meta-model includes a set of trust based concepts, which support the development of ODA trust boundaries for the Canvas and Components.

Integrity management provides a means by which distributed systems, such as present in cloud environments, can assess the trustability of environments and/or components. Root of Trust Installation (ROTI) has been a foundation for high integrity systems which also asserts the integrity of the target software perimeter. By incorporating ROTI as a standard means to measure and manage Integrity of software "systems", consumers of ODA Canvases and/or components can verify integrity guarantees.

2.3.1. Integrity Metamodel

(Ongoing work - Future work will incorporate integrity views from Developer, Provider, Consumer, Host points of view with implications on pipeline and platform operating models. This will capture concepts for Entity integrity, as well as Referential integrity.)

2.3.2. Trust Metamodel

(Ongoing Work)

3. Security and Privacy (SecPriv) Principles

3.1. ODA Component SecPriv Principles

3.1.1. High-level Security Concepts & Principles

*For more on Security implications please refer to IG1178 - ODA Governance and Security Risk Assessment

3.1.2. Privacy Principles

The European Union GDPR establishes a set of key requirements for Privacy:

• Lawfulness, fairness and transparency
• Purpose limitation
• Data minimization
• Accuracy
• Storage limitation
• Integrity and confidentiality (security)
• Accountability

The Privacy concepts in this section will be mapped to the Privacy Concepts identified here, along with the other regional (Canada, US, Australia etc.) Privacy requirements in order to ensure completeness.

3.2. ODA SecPriv Requirement Management

(future work)

3.3. Integrated SecPriv Metamodel

(future work)

4. SecPriv Ontology for ODA

This section answers the need for a common language for an ODA Security & Privacy ontology. It includes basic concepts, their intricate relations and describes main ideas. With the creation of this cohesive ODA Security and Privacy ontology, information security in an ODA implementation is efficiently communicated, designed, developed and shared with one understanding and standard language. It also provides the hierarchy of the ontology and the information it provides for specific concepts. We can use the hierarchy and information objects to categorize, for example, threats or countermeasures according to their security goal, asset or defense strategy by trust domain.

ODA, with its focus on digital ecosystems, digital business, digital services and digital operations, requires a security ontology for an all-digital target architecture that fulfills requirement management around the ODA realization lifecycle. It includes a gamut of security and privacy architecture operationalization best practices, while capturing the relationships between each entry within the ontology. This ensures that information security professionals can make faster and better decisions regarding design and implementation needs to improve operations and transition. This help to simplify the relationships between incidents, events and concepts to provide a valuable insight.

4.1.1. Security Ontology

Each of the concepts outlined here are defined and described within the domain and context of security. As a note, where the term host is used, it refers to a computer program, computing device, a computing service node.

4.1.2. Privacy Ontology

Each of the concepts here are defined within the context of privacy.

4.1.3. Benefits of ODA SecPriv Ontology

This ODA SecPriv taxonomy will enable information/cyber security professionals implementing ODA in ecosystems, or across different organizations and geographical regions to communicate faster and more efficiently using standard protocols. ODA SecPriv ontology is instrumental in facilitating the description of critical vulnerabilities, risk exposures and remediation techniques. With techniques for attacks and defense changing, TM Forum members can update and exchange information using the SecPriv metamodel and ontology and reduce widespread impact. The ODA SecPriv Ontology is also helpful in enhancing ODA component definition, ODA component capability modularization, Functional decoupling and integration requirements (using the ODA Threat Boundary model), and spot weak point ODA Engagement Management function with humans and Things. By employing the ODA SecPriv ontology, members can deploy resources managing ODA implementations more efficiently while discovering new digital technology products and capabilities.

5. Approach to Realize SecPriv Metamodel of ODA Component and ODA Canvas

Reference to ODA Enterprise Risk Assessment (IG1187) section 4, figure 4-2: ODA Function Architecture Logical Threat Boundaries, all Function blocks in ODA have unique and common security and privacy design patterns that can the metamodel helps to enumerate. This section identifies the common and unique SecPriv design considerations that can enable implementation and runtime needs.

fig 5.0 - SecPriv Scope Reference to ODA FA Trust Boundaries and Trust Domains

5.1. SecPriv, Integrity and Trust Requirements Modeling

The Information Systems Security Risks Management model (ISSRM) along with the ontology for Security, Privacy and Integrity models help in evaluating the Security, Privacy and Trust concerns across trust boundaries. The choice of ISSRM is to highlight the importance of Security-by-design and Privacy-by-design, with both concepts emphasizing the need to capture these concerns at the design and development stages.

For more on the details around the activities in the ISSRM, refer to IG1187 ODA Enterprise Risk Assessment for R20.0#COOKBOOKARiskAssessmentCookbook. The decision points in the ISSRM modeling approach hints on the need to be systematic in reviewing the applicability of controls to identified vulnerabilities and threats.

5.1.1. Engagement Management and Party Management Functions (Trust Boundary 4)

5.1.1.1. Scenario 1: ODA-EM <-> ODA-PM SecPriv, Integrity and Trust Requirements Model

fig 5.1 ODA FA EM and PM Component and Environment

Common SecPriv Vulnerability Concerns

Counter Measures

5.1.1.2. Scenario 2: ODA-EM <-> ODA-CCM SecPriv, Integrity and Trust Requirements Model

(Ongoing Study)

5.1.1.3. Scenario 2: ODA-EM <-> ODA-P SecPriv, Integrity and Trust Requirements Model

(Ongoing Study)

5.1.1.4. Scenario 2: ODA-EM <-> ODA-IM SecPriv, Integrity and Trust Requirements Model

(Ongoing Study)

5.1.2. Party Management and Core Commerce Management Function (Trust Boundary 5)

(Ongoing Study)

5.1.3. Party Management and Production Function - (Trust Boundary 6)

(Ongoing Study)

5.1.4. Party Management and Intelligence Management (Trust Boundary 7)

(Ongoing Study)

5.1.5. Core Commerce Management and Production (Trust Boundary 6)

(Ongoing Study)

5.1.6. Core Commerce Management and Intelligence Management (Trust Boundary 7)

(Ongoing Study)

5.1.7. Production and Intelligence Management Function- (Trust Boundary 7)

(Ongoing Study)

5.2. Unique ODA SecPriv, Integrity and Trust Requirement model

(Ongoing Study)

5.3. Common SecPriv, Integrity and Trust Requirement model

(Ongoing Study)

6. Conclusion

The conclusion is work in progress. It will eb finalized based on the modeling scenarios. While traditional thoughts have framed the implementation of ODA on one environment, this is likely not going to be the case. Private, public, hybrid, and serverless implementation strategies point to the need to address security, privacy, integrity and trust with a comprehensive array of solutions. Initial insights emerging from this work suggest each ODA Function block serves as a trust domain with a set of requirements that facilitate functional and non-functional management of security, privacy, integrity and trust.

The metamodels provided here for Security, Privacy, Integrity and Trust contexts will be used to help identify specifications that help in the defining design and implementation objectives for ODA Component, ODA Environments and Data handling within an ODA environment. As ODA FA advances the Lego-like framework for adjacent Function blocks to interact directly with each other, effectively understanding how Components and Environment in these trust boundaries are designed and implemented may result in some common as well as unique specifications.

Join the ongoing study.

7.  Appendix A: ODA Security Management

Rephael Benhamo 

There is a need to incorporate cognitive functions in the ODA AN archititeture as well as incorporting control loop functions to enable the following:

• Ensure a more detailed analysis of the ODA environemtn's state and historical data
• Tests and enhance cyber situational awareness and improve intrusion detection testing
• Learn complex attack patterns from historical data and generate generic rules that allow to detect variations of known attacks.
• Leveraging several inference engines for the different cognitive ODA environment management functions and security analytics on top of the data structure
• Retrieve data from log created knowledge to the Knowledge source. For example, the Orient function obtains information about the historical behavior of a managed entity

Cognitive Function in the AN Architecture Control Loop

• Observe function refers to the cognitive monitor that performs intelligent probing. For instance, when the network is overloaded, the Observe function may decide to reduce the probing rate and instead perform regression for data prediction. Or, Observe function should be able to determine what, when and where to monitor.
• Orient function detects, predicts changes in the domain environment (e.g., faults, policy violations, frauds, performance degradation and attacks).
• Decide function develops an intelligent automated engine that reacts to changes in the entity domain by selecting, composing changes, extracting and organization of knowledge (e.g., plans, tracks, execution traces), and eventually decides
• Act function schedule the generated execution and determine the course of action taken should the execution fail. Act agent exploits past successful experiences to generate optimal execution policies and explore new actions should the execution fail

7.1. ODA Security Management Model

An important aspect of the ODA security management model is ensuring that the management interface itself is secured. This is primarily achieved by limiting access to authorized users. However, it cannot guarantee safety against malicious authorized users. This involves defining and mathematically formulating the users, roles, and attributes within DTCLA such that the security digital thread can be monitored and traced. The set of users is denoted as and can be represented as:

Each user can have one or more roles as defined by the security framework. The set of roles is denoted as and can be represented as:

Additionally, users may have various attributes associated with them that provide additional information about the user. The set of attributes is denoted as and can be represented as:

These attributes can include information such as user demographics, organizational affiliations, or specific permissions granted to the user. Let's define the components, C, and relationships in the control model:

 C represents the components used for modeling attributes,

A. Attributes are defined as

And each attribute can be derived from a combination of components:

Permissions are defined as

which are derived from a user's role and attributes. These permissions are limited by the user's attributes and specify the access to objects.

Objects are defined as

and the allowed operation

and each object is associated with a component to link the relevant data to the component it belongs to:

This leads to the definition of permissions as

whereby it can be concluded that . The n-m relation of users to roles is expressed by indicating that each permission is associated with an object. The relationship between users and roles is expressed as

where  represents users and  represents roles. The relationship between users and attributes can be described as

Mapping the role-attribute combination to a user is defined as

Mapping the role-attribute combination to permissions is defined as

These definitions help establish the relationships and mappings between users, roles, attributes, permissions, and objects as outlined in TMF TR284G and the references specified, and TMF720 Digital Identitiy managemet API, TMF GB1008. 

8. Appendix B: Terms & Abbreviations Used within this Document

8.1. Terminology

8.2. Abbreviations & Acronyms

9. Appendix B: References

10. Administrative Appendix

This Appendix provides additional background material about the TM Forum and this document. In general, sections may be included or omitted as desired; however, a Document History must always be included.

10.1. Document History

10.1.1. Version History

10.1.2. Release History

10.2. Company Contact Details

10.3. Acknowledgments

This document was prepared by the members of the TM Forum  team:

• Brian Burton, Vodafone, Contributor
• Abinash Vishwakarma , Netcracker, Participant
• Konstantin Petrosov, T-systems.com, Participant