The NGOSS Security Principles

TMF 053S

Member Evaluation
Version 1.0
January 2004

 TeleManagement Forum 2004

TMF 053 v1.0 TeleManagement Forum 2004 1

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

NOTICE

The TeleManagement Forum (“TM Forum”) has made every effort to ensure that the contents of this document
are accurate. However, no liability is accepted for any errors or omissions or for consequences of any use made
of this document.

This document is a draft working document of TM Forum and is provided to its members solely for formal
comments and evaluation. It is not a Forum Approved Document and is solely circulated for the purposes of
assisting TM Forum in the preparation of a final document in furtherance of the aims and mission of TM Forum.
Any use of this document by the recipient is at its own risk. Under no circumstances will TM Forum be liable for
direct or indirect damages or any costs or losses resulting from the use of this document by the recipient.

Members of TM Forum are granted limited copyright waiver to distribute this document within their companies.
They may not make paper or electronic copies for distribution outside their companies. The only purpose of the
provision of this draft document to members is for making formal comments thereon to TM Forum.

This document may involve a claim of patent rights by one or more TM Forum members, pursuant to the
agreement on Intellectual Property Rights between TM Forum and its members, and by non-members of TM
Forum.

Direct inquiries to the TM Forum office:

89 Headquarters Plaza North – Suite 350
Morristown, NJ 07960 USA
Tel No. +1 973 292 1901
Fax No. +1 973 993 3131
TM Forum Web Page: www.tmforum.org

2 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

ACKNOWLEDGMENTS

The TeleManagement Forum would like to acknowledge the contribution made to this effort by the following
people:

Amr Elkady Alcatel (Editor and Rapporteur)

Cliff Faurer TeleManagement Forum

Joel Fleck Hewlett-Packard

Bertrand Marquet Alcatel

Jean-Marc Robert Alcatel

Alex Tosheff SPVC

Richard Vinnicombe Qinetiq

Stuart Ward Orange Telecom

TMF 053s v1.0 TeleManagement Forum 2004 3

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

ABOUT THIS DOCUMENT

TM Forum Documents
The NGOSS Security Principles Specifications Annex (TMF053S) to the NGOSS Technology Neutral Architecture
Specification (TMF 053) is being issued as Member Evaluation Version 1.0.

The purpose of an Evaluation Version is to encourage input based on experience of members and the public as
they begin to use the document. Following the Evaluation Period, documents that are seen to deliver value are
candidates for formal approval by the TM Forum. All documents approved by the TM Forum undergo a formal
review and approval process.

This document will continue under formal change control. Further work will be reflected in revisions to this
document.

Revision History

Version Date Who Purpose

0.1 2002.10.06 S.Ward Initial proposal

0.2 2003.02.27 TMF Formatted for member draft release

0.3 2003.03.03 A. Elkady Reedit and reformat

1.0 2003.12.02 A. Elkady Final adoption of CC.

1.0.1 2004.01.30 TMF Template & cosmetic changes prior to Member

Evaluation.

Time Stamp
This version of the NGOSS Security Principles Specification, TMF 053S Version 1.0, can be considered valid until
December 2004.

How to obtain a copy

An electronic copy of this document can be downloaded at the TM Forum Web Site (www.tmforum.org),
Publications or through a link to Publications from a specific team’s public project area.

If the document version has only been released to members for review and comment, the document can be
downloaded from the Members Only area of the TM Forum Web Site.

Paper versions can be made available for a small fee to cover copying, mailing and handling. If you would like a
paper version of this document, please order via the TM Forum Web Site or contact the TM Forum office. If you
are not a member, please contact the TM Forum office on +1 973-292-1901.

4 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

How to comment on the document

Comments must be in written form and addressed to the team editor for review with the project team. Please
send your comments to the editor using the editor’s e-mail shown below.

Amr Elkady, ALCATEL [email protected] (team lead and rapporteur)

Cliff Faurer, TM Forum [email protected]

TMF 053s v1.0 TeleManagement Forum 2004 5

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

TABLE OF CONTENTS

TM Forum Documents ........................................................................................................................................... 4

Revision History ..................................................................................................................................................... 4

Time Stamp............................................................................................................................................................ 4

How to obtain a copy ............................................................................................................................................. 4

How to comment on the document ........................................................................................................................ 5

About TeleManagement Forum ............................................................................................................................. 9

1 Introduction....................................................................................................................................................... 10

1.1 Background ............................................................................................................................................... 10

1.2 Goals and Objectives ................................................................................................................................ 10

1.3 Intended Audience .................................................................................................................................... 10

2 The NGOSS Architecture ................................................................................................................................. 11

2.1 Security in NGOSS Solution Life Cycle (this has to be modified)............................................................. 14

3 OSS Security Objectives .................................................................................................................................. 15

3.1 Overview ................................................................................................................................................... 15

3.2 Objectives ................................................................................................................................................. 15

4 Security Threats ............................................................................................................................................... 17

4.1 Eavesdropping .......................................................................................................................................... 18

4.2 Alteration ................................................................................................................................................... 18

4.3 Insertion..................................................................................................................................................... 18

4.4 Service Hijack ........................................................................................................................................... 18

4.5 Denial of Service ....................................................................................................................................... 18

4.6 Masquerade .............................................................................................................................................. 18

4.7 Fraud ......................................................................................................................................................... 18

5 Threat Analysis................................................................................................................................................. 19

6 Detailed controls............................................................................................................................................... 22

Assurance requirements............................................................................................................................... 22

6 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

6.1 ........................................................................................................................................................................ 22

7 References ....................................................................................................................................................... 30

TMF 053s v1.0 TeleManagement Forum 2004 7

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

LIST OF FIGURES

Figure 1: Structure of NGOSS Architecture ............................................................................................... 11

Figure 2: Security in NGOSS life Cycle...................................................................................................... 14

Figure 4: NGOSS Security Threats vs Context .......................................................................................... 17

8 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

PREFACE

About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service providers and their suppliers.
Its mission is to help service providers and network operators automate their business processes in a cost- and
time-effective way. Specifically, the work of the TM Forum includes:

• Establishing operational guidance on the shape of business processes

• Agreeing on information that needs to flow from one process activity to another

• Identifying a realistic systems environment to support the interconnection of operational support systems

• Enabling the development of a market and real products for integrating and automating telecom operations
processes

The members of TM Forum include service providers, network operators and suppliers of equipment and
software to the communications industry. With that combination of buyers and suppliers of operational support
systems, TM Forum is able to achieve results in a pragmatic way that leads to product offerings (from member
companies) as well as paper specifications.

TMF 053s v1.0 TeleManagement Forum 2004 9

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

1 TeleManagement Forum supports several kinds of projects, including

Process Automation and Technology Integration projects, as well as
Catalyst Projects that support both Process Automation and
Technology Integration projects through real-product integration.
Introduction

1.1 Background
Today, customers and stakeholders’ security awareness and expectations are growing. It is crucial to deal with
new challenging requirements for providing a secure NGOSS system.

For a long time, the security of Network Operations and Management Systems was taken for granted, mainly
because of the two following assumptions:

1. The Network Management System (NMS) runs in a trusted environment

2. The Management Network is dedicated, well demarcated, and protected against access from the outside

But customers are less and less inclined to consider these assumptions as sufficient in order to claim to have a
secure System. In recent RFPs or RFIs, customers explicitly asked not to make such security assumptions and
therefore clearly requested some security features to be included from vendors’ solutions.

This document explains why the two assumptions listed above are not sufficient anymore to make a claim of
Management System security and, as a result, why NGOSS security is an issue that must be tackled. This
document will also provide the infrastructure, concepts and requirements for a secure NGOSS system.

1.2 Goals and Objectives

This specification is concerned with the definition of the basic principles that enable a secure system to be built
using the NGOSS technology neutral architecture. It is also concerned with defining how security principles can
be applied to the system. This specification is not concerned with specifying in detail how to implement a security
policy and/or components. Rather, this specification defines the architectural principles by which a secure
environment can be created within an NGOSS system.

1.3 Intended Audience

As the focus of the NGOSS Security annex is on how to introduce a secure implementation where an NGOSS
system can operate, the key stakeholders of interest will be System Integrators and Independent Software
Vendors along with Service Providers and Network Equipment Providers. Within these stakeholder groups there
will be a number of different roles, or users, of this document.

10 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

2 The NGOSS Architecture

The NGOSS architecture represents a facility for constructing distributed systems that support business
processes associated with managing information and communications services domains. It provides a
technology-neutral way of describing the structure of these systems, composed from a series of Components
making use of technology-specific implementations of basic services.

This section provides an overview of the Structure of the NGOSS architecture. Rather than providing a
comprehensive look into the architecture (as provided by the TMF053 series of NGOSS Technology Neutral
Architecture (TNA) documents), it is meant to provide a quick look at and definition of the key NGOSS
architecture structural parts. For further details, interested readers should refer to the various TMF documents
listed in the References at the end of this document.

Figure 1: Structure of NGOSS Architecture

As illustrated in figure 1, The NGOSS architecture specifies the following layered approach:

Shared Information Model:

An NGOSS system must be characterized by the usage of a common information model for enabling integration
and interoperability. The information model is designed to be more than just a standard representation of data – it
also defines semantics and behavior of, and interaction between, managed entities. This set of information, all
provided in a standard representation using standard data types is used to describe domain information (e.g.,
orders, network service and configuration definitions) in an NGOSS system.

TMF 053s v1.0 TeleManagement Forum 2004 11

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

Security Model:

An NGOSS system should be designed according to an overarching security model. An implementation of an

NGOSS system will require the setup and operation of one or more security mechanisms and policies in order to
operate the NGOSS system in a secure manner.

Policy Management Model:

The NGOSS system architecture is defined as a policy-enabled management architecture. Policy rules are
defined to meet business, system, or other objectives; consequently, policies may link one or more of the
business, system (operational), and implementation views of the NGOSS system to each other.

Business Process Model:

An NGOSS system should be composed of defined services that can be orchestrated using scripting/process
management technologies. An NGOSS system is further characterized by externalized descriptions of behavior
expressed in a technology-neutral manner.

OSS Business Services:

An OSS Business service provides services that support the business-related functionality of the NGOSS
architecture, such as billing, rating and discounting, network data management, and others. OSS Business
Services deployed in an NGOSS solution are characterized as follows:

NGOSS Integrated Applications:

NGOSS Integrated Applications are software components designed from the start for deployment in an
NGOSS environment.
Integrated Legacy Applications:

Integrated Legacy Applications are software components that were developed outside the scope of
NGOSS architecture and that have subsequently been made available as NGOSS components.

Framework Services:

These services provide the functionality to implementations of the architecture for correctly operating. Interfaces
to these services are provided through appropriate contract specifications and can be further split into two sub
classes:

OSS Framework Services:

These Services provide standard OSS/BSS capabilities whose functionality is common to many
OSS/BSS services and which can be orchestrated by those OSS/BSS Services. Examples of OSS
Framework Services include: Logging Services, Tracing Services, etc.

Basic Framework Services:

These Services provide the capabilities needed to support the patterns of interaction between
Components implementing Business Services. The Basic Framework Services may also be used by the
other Services. The Basic Framework Services are not optional. Each NGOSS deployment must include
at least one instance of each of the Distribution and Transparency Services that comprise the Basic
Framework Services.

12 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

Distribution and Transparency Services:

The TNA Distribution and Transparency Services are NGOSS Technology Neutral Architecture
framework level services that are fundamental to the construction, deployment and use of
solutions in an NGOSS environment. An instance of each Service must be included in each
NGOSS deployment. D&T Framework Services include:
• Naming: to shield prospective users from the complexities (and inherent
incomprehensibility) of network addresses
• Repositories (or registry services): Store and provide information about available
distributed services
• Registration Services: Provide for the administration of services including the addition,
modification and removal of services from the Repository, and the ability to browse
services previously added to the Repository
• Service Location Services: Facilitate “matchmaking” between potential clients and
servers. These Services accept requests for a particular service from potential clients
and match that request against registered providers for that service stored in the
Repository.
Federation Model:

There are generally two types of methods of federating systems services and data: either by
providing a communications protocol between services providing similar functions (Service Level
Federation), or by providing mechanisms by which the underlying data (both system and user)
can be shared (Repository Level Federation).

Basic Mechanisms:

These Mechanisms provide the baseline functionality which must be implemented in any NGOSS deployment to
provide for the inter-working between independently deployed Components and to support the “plug-and-work”
paradigm at the most fundamental level.

TMF 053s v1.0 TeleManagement Forum 2004 13

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

2.1 Security in NGOSS Solution Life Cycle (this has to be modified)

Figure 2: Security in NGOSS life Cycle

14 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

3 OSS Security Objectives

3.1 Overview
The design of the NGOSS security architecture aims to provide a basis for stakeholders to architect, deploy, test
and operate an NGOSS environment in a secure manner. Although the macro-level objectives for security
(ultimately; business function and continuity) are common to all entities, it should be noted that each stakeholder
type may have a unique requirement or philosophy pertaining to function and at certain times these requirements
may be disjoint. Security is a cyclical process of assessment of need, planning of solutions, implementation of
solutions and monitoring. The stakeholders will ultimately choose the level of security necessary to maintain
respective business value, but at a minimum the guidelines within this document shall relate a common and
standard set of principles and practices from which to start.

A useful framework for the purposes of this document is a model relating subjects to objects in the context of
major security attributes (or goals) commonly utilized in the discussion of security:

Security Context

• Confidentiality • Integrity

• Availability • Attribution (non-Repudiation)

This is model is commonly referred to as the “security context” of a particular element, operator or activity.

In the NGOSS standards, subjects could be people or software controls acting upon objects such as network
elements or services. Each NGOSS framework specification or recommendation shall be required to clearly state
the method by which it achieves security by highlighting its behavior against each security context.

3.2 Objectives
The macro-level goals of the NGOSS security architecture common to all stakeholders are:
a) To ensure that confidential information generated by or relating to a user is adequately protected against
misuse or misappropriation;

b) To ensure that the organizations and their employees are adequately protected form internal and external
threats when operating an NGOSS environment;

c) To ensure that there are clear lines of responsibility between entities, both inter and intra company, so that
liability for resources and services can be attributed and accounted for;

d) To ensure that the resources and services provided by networks and environments are adequately
protected against misuse or misappropriation;

e) to ensure that the level of protection afforded to users and providers of services follows the best practices
of the telecommunications industry available;

f) To ensure that the implementation of NGOSS security features and mechanisms can be extended and
enhanced as required by new threats and services.

g) To ensure OA&M and FCAPS functions perform as expected within the appropriate security context.

TMF 053s v1.0 TeleManagement Forum 2004 15

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

It is certain that each stakeholder constituency will have unique security goals (examples provided in the following
table) and will place different values on security context elements, relative to the economic value of the service or
product.

Stakeholder: Service Systems Independent Network

Provider (SP) Integrator (SI) Software Vendor Equipment
(ISV) Provider (NEP)

Example security goals: Availability, Confidentiality Integrity, attribution Integrity, attribution

Authorization,
attribution

16 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

4 Security Threats
The first step in designing security architecture is to perform a detailed threat and threat analysis in order to
define the possible attacks against which the system must be protected. The threat analysis must consider every
component of the system and all interactions between functional components. In this section, we list several kinds
of threats that must be considered.

Confidentiality

Availability 5 4 6 2 Integrity

7 1. Eavesdropping
2. Alteration
3. Insertion
4. Service Hijacking
5. Denial of Service
6. Masquerade
7. Fraud
Attribution

Figure 3: NGOSS Security Threats vs. Context

TMF 053s v1.0 TeleManagement Forum 2004 17

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

4.1 Eavesdropping
Eavesdropping is a form of attack wherein an unauthorized user seeks to gain knowledge from or about a system
component by intercepting system communications. This can be done using such techniques as wiretapping or
man-in-the-middle attacks. Encryption can be used to prevent eavesdropping.

4.2 Alteration
Alteration is when an attacker manages to make unauthorized changes to files and components in the system. A
major concern with this type of attacks is its possibility to render the intrusion detection systems useless by
altering their policy rules or changing selected log files. And by changing or erasing log files for example, it
becomes impossible to trace the attacker’s activity in the system.

4.3 Insertion
The insertion of malicious code or replacement of a systems’ module with another that contains a Trojan horse or
malicious code is a common type of this threat. Attacker can also insert false entries into log files, add new users,
or add extra privileges to a user on the system. Checksums and encryption techniques can be helpful against this
type of attacks.

4.4 Service Hijack

Hijack is where the session of a legitimate user is taken over by an attacker in order to bypass the authentication
process. Generally it will be necessary to have some form of authentication on every packet entering the system
to avoid hijack. Care should be taken in relying on encryption techniques in order to protect against hijack attacks.

4.5 Denial of Service

Denial of service is a form of attack that seeks to render the component being attacked unusable by authorized
users. This is often done by keeping critical resources of the attacked component busy serving requests issued
by the attacker. Redundancy is often used to protect against denial of service attacks. Good system design
includes spending the least possible resources processing requests until the issuer can be authenticated and
authorized. Protecting the access network against unauthorized access can help protect systems on the network.
Security logs can be helpful in diagnosing and stopping denial of service activity.

4.6 Masquerade
A masquerade attack consists in posing as an authorized user in order to obtain unauthorized services or
otherwise compromise the security of system components. Strong authentication is a protection against
masquerade attacks.

4.7 Fraud
Fraud is generally an attack against the economic interests of the network administration. Authentication,
authorization, message authenticator codes, digital signatures, encryption, audits, and security logs all help
protect against fraud.

18 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

5 Threat Analysis

3.1.1 Access Registration Service access control Component Designer must have write
access to the Registry authenticated,
and these credentials presented to the
Registration Service

3.1.2 Access Registry access control Registration Service must have an

existing security association with the
Registry

3.1.3 Access Client access control The Component Designer will have
registered the Prospective Client and
assigned it an Access Control List
allowing it to perform the minimum
necessary actions.

3.1.4 Access Client access control The Prospective Client will present its
credentials to the Access Control
Function to be authenticated.

3.2.1 Authorizat Contract Type access control The Registration Server will only allow
ion administration of Contract Type(s) that
the Component Designer’s credentials
allow him to access

3.3.1 Denial of An attacker sends Uninstall messages to Component modification messages shall
Service a legitimate component in order to be authenticated and integrity protected
disrupt service using cryptographically generated digital
signatures.

3.3.2 Denial of An attacker modifies the Component to Component modification messages will
Service disable the use of that component by be authenticated and integrity protected
legitimate users cryptographically generated digital
signatures.

3.3.3 Denial of An attacker registers multiple Contract The System will allow the System
Service Types in order to Deny Service to Administrator to set limits on the number
legitimate users of Contract Instances that may be
registered for a user. In order to fully
control the balance between service
availability and fraud control the System
Administrator will need to continually
monitor and adjust these limits.

3.3.4 Denial of An attacker modifies the Contract Type Contract Type modification messages
Service to disable the use of that contract type by shall be authenticated and integrity
legitimate users protected using cryptographically
generated digital signatures.

TMF 053s v1.0 TeleManagement Forum 2004 19

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

3.3.5 Denial of An attacker intercepts a Contract Type Contract Instantiation messages shall be
Service message and modifies elements of the authenticated and integrity protected
message in order to gain services or using a cryptographically generated
deny service to legitimate users. This digital signature. The System
might be done in a symmetric fashion in Administrator will need to maintain an
order to satisfy message integrity or audited list of Component Designers who
message encryption. are allowed to Instantiate Contract
Types.

3.3.6 Denial of An attacker acts as a service Clients using services must verify the
Service (Advertising Contract Instances) and signatures on advertised contracts and
advertises services in order to capture have a process of specifying those
legitimate clients and deny service to signatures that will be acceptable.
legitimate services

3.3.7 Denial of An attacker requests multiple services The system will allow the System
Service (Contract Instances) in order to fill up the Administrator to set limits on the number
matching service capacity and deny of services an individual may request. In
service to others order to fully control the balance between
service availability and fraud control the
System Administrator will need to
continually monitor and adjust these
levels.

3.3.8 Denial of An attacker intercepts a Contract It is important that the messages to and
Service Instance message and modifies from the registry for advertising contract
elements of the message in order to gain instances are integrity protected. It is
services or deny service to legitimate proposed that these messages are
users. This might be done in a symmetric signed using a cryptographically
fashion in order to satisfy message generated digital signature protocol.
integrity or message encryption.

3.3.9 Denial of An attacker disables access to a Contract Instance modification messages

Service Contract Instance by legitimate users by shall be authenticated and integrity
modifying status, or attributed of a protected using cryptographically
Contract Instance generated digital signatures. Modification
will only be allowed to Component
Designers who have authenticated write
access to this Contract Type.

3.3.10 Denial of The Registration Service must be able to Where the Registration service is
Service identify and block particular sources of available outside a trusted network, it will
Contract Type registrations that may be be required to have devices to filter the
attempting to block legitimate access to connections to deny access to particular
the Registration Service resources (Firewalls). It may also be
required to have systems examining
connections to look for anomalous
behavior (Intruder Detection Systems).

3.3.11 Denial of Removal of a Contract Type thus The System Integrator must have
Service causing all Contract Instances of that authorization and follow the business
type to be unavailable rules (policy) for deprecating this
Contract Type

20 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

3.3.12 Denial of The Registration Service should have Where the Registration service is
service sufficient capability to quickly drop and available outside a trusted network, it will
filter requests to prevent DoS attacks be required to have devices to filter the
connections to deny access to particular
sources (Firewalls). It may also be
required to have systems examining
connections to look for anomalous
behavior (Intruder Detection Systems).

3.4.1 Disaster The failure of a significant part of the The NGOSS system and its components
Recovery NGOSS infrastructure. will be implemented in a manner to allow
for replication of the data across multiple
physical devices at multiple locations to
allow for the operation of a resilient
system.

3.5.1 Eavesdro The connections between the The process of connecting to the
pping Registration Service, the Registry and Registration service or the Registry will
the Component designer shall be establish an encrypted session if the
encrypted authentication procedure is successful.

3.6.1 Fraud A legitimate user sets up many Contract The controls on the number and type of
Instances and is then unable to pay for Contract Instances that a user can
the services used. establish will be limited. The system
Administrator and the Fraud department
will need to continually monitor and
adjust these levels.

3.6.2 Fraud An attacker sets up as a legitimate user The controls on the number and type of
and then sets up as many Contract Contract Instances that a user can
Instances as possible with no intention to establish will be limited. The system
pay for the services Administrator and the Fraud department
will need to continually monitor and
adjust these levels.

3.7.1 Service An attacker installs a component in order Component Designer must have write
Hijack to disrupt, or misappropriate service access to the Registry authenticated,
and these credentials presented to the
Registration Service

3.7.2 Service A Contract Type is Registered by an The Registration Server will only allow
Hijack attacker that is trying to capture services registration of Contract Type(s) that the
from legitimate users Component Designer’s credentials allow
him to register.

3.7.3 Service An attacker sets up a Contract Instance The Component Designer must have
Hijack that mimics a legitimate Contract authenticated rights to use the Contract
Instance and captures legitimate Type identifier.
connections to a service.

TMF 053s v1.0 TeleManagement Forum 2004 21

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

6 Detailed controls
This section is based on the International Standards Organization (ISO) security standard and the International
Engineering consortium [ISO/IEC 15408] also known as Common Criteria. The aim is to put the specific controls
required by the NGOSS standard into this framework. Organizations or Companies already adopting this
standard will then have a simple task of integrating NGOSS security environment into their existing security
controls.

6.1 Assurance requirements

Evaluation assurance level 2 (EAL2) - structurally tested

EAL2 requires the co-operation of the developer in terms of the delivery of design information and test results, but
should not demand more effort on the part of the developer than is consistent with good commercial practice. As
such it should not require a substantially increased investment of cost or time.

EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level
of independently assured security in the absence of ready availability of the complete development record. Such
a situation may arise when securing legacy systems, or where access to the developer may be limited.

EAL2 (see next figure) provides assurance by an analysis of the security functions, using a functional and
interface specification, guidance documentation and the high-level design of the TOE, to understand the security
behavior. The analysis is supported by independent testing of the TOE security functions, evidence of developer
testing based on the functional specification, selective independent confirmation of the developer test results,
strength of function analysis, and evidence of a developer search for obvious vulnerabilities (e.g. those in the
public domain).

EAL2 also provides assurance through a configuration list for the TOE, and evidence of secure delivery
procedures. This EAL represents a meaningful increase in assurance from EAL1 by requiring developer testing, a
vulnerability analysis, and independent testing based upon more detailed TOE specifications.

22 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

Assurance class Assurance components

Class ACM: Configuration management

CM capabilities (ACM_CAP)
ACM_CAP CM capabilities

The capabilities of the CM system address the likelihood that accidental or unauthorized modifications of the
configuration items will occur. The CM system should ensure the integrity of the TOE from the early design stages
through all subsequent maintenance efforts.

The objectives of this family include the following:

a) Ensuring that the TOE is correct and complete before it is sent to the consumer;
b) Ensuring that no configuration items are missed during evaluation;
c) Preventing unauthorized modification, addition, or deletion of TOE configuration items.

ACM_CAP.2 Configuration items

A unique reference is required to ensure that there is no ambiguity in terms of which instance of the TOE is being
evaluated. Labeling the TOE with its reference ensures that users of the TOE can be aware of which instance of
the TOE they are using.

Unique identification of the configuration items leads to a clearer understanding of the composition of the TOE,
which in turn helps to determine those items which are subject to the evaluation requirements for the TOE.

Dependencies:
No dependencies.

Developer action elements:

ACM_CAP.2.1D The developer shall provide a reference for the TOE.
ACM_CAP.2.2D The developer shall use a CM system.
ACM_CAP.2.3D The developer shall provide CM documentation.
ACM_CAP.2.1C The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.2.2C The TOE shall be labeled with its reference.
Content and presentation of evidence elements:
ACM_CAP.2.3C The CM documentation shall include a configuration list.
ACM_CAP.2.4C The configuration list shall describe the configuration items that comprise the TOE.
ACM_CAP.2.5C The CM documentation shall describe the method used to uniquely identify the
configuration items.
ACM_CAP.2.6C The CM system shall uniquely identify all configuration items.

Class ADO: Delivery and operation

The requirements for delivery call for system control and distribution facilities and procedures that provide
assurance that the recipient receives the TOE that the sender intended to send, without any modifications. For a
valid delivery, what is received must correspond precisely to the TOE master copy, thus avoiding any tampering
with the actual version, or substitution of a false version

ADO_DEL.1 Delivery procedures

Dependencies:
No dependencies.

Developer action elements:

ADO_DEL.1.1D The developer shall document procedures for delivery of the TOE or parts of it to the
user.

TMF 053s v1.0 TeleManagement Forum 2004 23

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

ADO_DEL.1.2D The developer shall use the delivery procedures.

Content and presentation of evidence elements:

ADO_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to maintain security
when distributing versions of the TOE to a user’s site.

ADO_IGS.1 Installation, generation, and start-up procedures

Dependencies:
AGD_ADM.1 Administrator guidance

Developer action elements:

ADO_IGS.1.1D The developer shall document procedures necessary for the secure installation,
generation, and start-up of the TOE.

Content and presentation of evidence elements:

ADO_IGS.1.1C The documentation shall describe the steps necessary for secure installation, generation,
and start-up of the TOE.

Class ADV: Development

The development class encompasses four families of requirements for representing the TSF at various levels of
abstraction from the functional interface to the implementation representation. The development class also
includes a family of requirements for a correspondence mapping between the various TSF representations,
ultimately requiring a demonstration of correspondence from the least abstract representation through all
intervening representations to the TOE summary specification provided in the ST. In addition, there is a family of
requirements for a TSP model, and for correspondence mappings between the TSP, the TSP model, and the
functional specification. Finally, there is a family of requirements on the internal structure of the TSF, which
covers aspects such as modularity, layering, and minimization of complexity.

ADV_FSP.1 Informal functional specification

Dependencies:
ADV_RCR.1 Informal correspondence demonstration
Developer action elements:
ADV_FSP.1.1D The developer shall provide a functional specification.
Content and presentation of evidence elements:
ADV_FSP.1.1C The functional specification shall describe the TSF and its external interfaces
using an informal style.
ADV_FSP.1.2C The functional specification shall be internally consistent.
ADV_FSP.1.3C The functional specification shall describe the purpose and method of use of all external
TSF interfaces, providing details of effects, exceptions and error messages, as appropriate.
ADV_FSP.1.4C The functional specification shall completely represent the TSF.

ADV_HLD.1 Descriptive high-level design

Dependencies:
ADV_FSP.1 Informal functional specification
ADV_RCR.1 Informal correspondence demonstration
Developer action elements:
ADV_HLD.1.1D The developer shall provide the high-level design of the TSF.
Content and presentation of evidence elements:
ADV_HLD.1.1C The presentation of the high-level design shall be informal.
ADV_HLD.1.2C The high-level design shall be internally consistent.
ADV_HLD.1.3C The high-level design shall describe the structure of the TSF in terms of subsystems.
ADV_HLD.1.4C The high-level design shall describe the security functionality provided by each
subsystem of the TSF.

24 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

ADV_HLD.1.5C The high-level design shall identify any underlying hardware, firmware, and/or software
required by the TSF with a presentation of the functions provided by the supporting protection
mechanisms implemented in that hardware, firmware, or software.
ADV_HLD.1.6C The high-level design shall identify all interfaces to the subsystems of the TSF.
ADV_HLD.1.7C The high-level design shall identify which of the interfaces to the subsystems of the TSF are
externally visible.

ADV_RCR.1 Informal correspondence demonstration

Dependencies:
No dependencies.

Developer action elements:

ADV_RCR.1.1D The developer shall provide an analysis of correspondence between all adjacent pairs of TSF
representations that are provided.

Content and presentation of evidence elements:

ADV_RCR.1.1C For each adjacent pair of provided TSF representations, the analysis shall demonstrate that all
relevant security functionality of the more abstract TSF representation is correctly and completely refined in the
less abstract TSF representation.

Class AGD: Guidance documents

The guidance documents class provides the requirements for user and administrator guidance documentation.
For the secure administration and use of the TOE it is necessary to describe all relevant aspects for the secure
application of the TOE.

AGD_ADM.1Administrator guidance
Dependencies:
ADV_FSP.1 Informal functional specification

Developer action elements:

AGD_ADM.1.1D The developer shall provide administrator guidance addressed to system administrative
personnel.

Content and presentation of evidence elements:

AGD_ADM.1.1C The administrator guidance shall describe the administrative functions and interfaces
available to the administrator of the TOE.
AGD_ADM.1.2C The administrator guidance shall describe how to administer the TOE in a secure
manner. The administrator guidance shall contain warnings about functions and privileges that should be
controlled in a secure processing environment.
AGD_ADM.1.4C The administrator guidance shall describe all assumptions regarding user behavior that
are relevant to secure operation of the TOE.
AGD_ADM.1.5C The administrator guidance shall describe all security parameters under the control of
the administrator, indicating secure values as appropriate.
AGD_ADM.1.6C The administrator guidance shall describe each type of security-relevant event relative
to the administrative functions that need to be performed, including changing the security characteristics
of entities under the control of the TSF.
AGD_ADM.1.7C The administrator guidance shall be consistent with all other documentation supplied for
evaluation.
AGD_ADM.1.8C The administrator guidance shall describe all security requirements for the IT
environment that are relevant to the administrator.

AGD_USR.1 User guidance

Dependencies:

TMF 053s v1.0 TeleManagement Forum 2004 25

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

ADV_FSP.1 Informal functional specification

Developer action elements:

AGD_USR.1.1D The developer shall provide user guidance.

Content and presentation of evidence elements:

AGD_USR.1.1C The user guidance shall describe the functions and interfaces available to the non-administrative
users of the TOE.
AGD_USR.1.2C The user guidance shall describe the use of user-accessible security functions provided by the
TOE.
AGD_USR.1.3C The user guidance shall contain warnings about user-accessible functions and privileges that
should be controlled in a secure processing environment.
AGD_USR.1.4C The user guidance shall clearly present all user responsibilities necessary for secure operation
of the TOE, including those related to assumptions regarding user behaviour found in the statement of TOE
security environment.
AGD_USR.1.5C The user guidance shall be consistent with all other documentation supplied for evaluation.
AGD_USR.1.6C The user guidance shall describe all security requirements for the IT environment that are
relevant to the user.

Class ATE: Tests

The class “Tests” encompasses four families: coverage (ATE_COV), depth (ATE_DPT), independent testing (e.g.
functional testing performed by evaluators) (ATE_IND), and functional tests (ATE_FUN). Testing helps to
establish that the TOE security functional requirements are met. Testing provides assurance that the TOE
satisfies at least the TOE security functional requirements, although it cannot establish that the TOE does no
more than what was specified. Testing may also be directed toward the internal structure of the TSF, such as the
testing of subsystems and modules against their specifications.
The aspects of coverage and depth have been separated from functional tests for reasons of increased flexibility
in applying the components of the families. However, the requirements in these three families are intended to be
applied together.

ATE_COV.1 Evidence of coverage

In this component, the objective is to establish that the TSF has been tested against its functional specification.
This is to be achieved through an examination of developer evidence of correspondence.

While the testing objective is to cover the TSF, there is no requirement to provide anything to verify this assertion
other than an informal mapping of tests to the functional specification and the testing data itself.
n this component the developer is required to show how the tests that have been identified correspond to the TSF
as described in the functional specification. This can be achieved by a statement of correspondence, perhaps
using a table. This information is required to support the evaluator in planning the test program for the evaluation.
At this level there is no requirement for complete coverage of every aspect of the TSF by the developer, and the
evaluator will need to take account of any deficiencies in this area.

Dependencies:
ADV_FSP.1 Informal functional specification
ATE_FUN.1 Functional testing

Developer action elements:

ATE_COV.1.1D The developer shall provide evidence of the test coverage.

Content and presentation of evidence elements:

ATE_COV.1.1C The evidence of the test coverage shall show the correspondence between the tests identified in
the test documentation and the TSF as described in the functional specification.

ATE_FUN.1 Functional testing

26 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

The objective is for the developer to demonstrate that all security functions perform as specified. The developer is
required to perform testing and to provide test documentation.

Dependencies:
No dependencies.

Developer action elements:

ATE_FUN.1.1D The developer shall test the TSF and document the results.
ATE_FUN.1.2D The developer shall provide test documentation.

Content and presentation of evidence elements:

ATE_FUN.1.1C The test documentation shall consist of test plans, test procedure descriptions, expected
test results and actual test results.
ATE_FUN.1.2C The test plans shall identify the security functions to be tested and describe the goal of
the tests to be performed.
ATE_FUN.1.3C The test procedure descriptions shall identify the tests to be performed and describe the
scenarios for testing each security function. These scenarios shall include any ordering dependencies on
the results of other tests.
ATE_FUN.1.4C The expected test results shall show the anticipated outputs from a successful execution
of the tests.
ATE_FUN.1.5C The test results from the developer execution of the tests shall demonstrate that each
tested security function behaved as specified.

ATE_IND.2 Independent testing - sample

The objective is to demonstrate that the security functions perform as specified. Evaluator testing includes
selecting and repeating a sample of the developer tests. The intent is that the developer should provide the
evaluator with materials necessary for the efficient reproduction of developer tests. This may include such things
as machine-readable test documentation, test programs, etc.

This component contains a requirement that the evaluator has available test results from the developer to
supplement the program of testing. The evaluator will repeat a sample of the developer’s tests to gain confidence
in the results obtained. Having established such confidence the evaluator will build upon the developer’s testing
by conducting additional tests that exercise the TOE in a different manner. By using a platform of validated
developer test results the evaluator is able to gain confidence that the TOE operates correctly in a wider range of
conditions than would be possible purely using the developer’s own efforts, given a fixed level of resource. Having
gained confidence that the developer has tested the TOE, the evaluator will also have more freedom, where
appropriate, to concentrate testing in areas where examination of documentation or specialist knowledge has
raised particular concerns.

Dependencies:
ADV_FSP.1 Informal functional specification
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
ATE_FUN.1 Functional testing

Developer action elements:

ATE_IND.2.1D The developer shall provide the TOE for testing.

Content and presentation of evidence elements:

ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that were used in the
developer’s functional testing of the TSF.

TMF 053s v1.0 TeleManagement Forum 2004 27

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

Class AVA: Vulnerability Assessment

Strength of TOE security functions (AVA_SOF)

AVA_SOF.1 Strength of TOE security function evaluation

AVA_SOF Strength of TOE security functions
Even if a TOE security function cannot be bypassed, deactivated, or corrupted, it may still be possible to defeat it
because there is vulnerability in the concept of its underlying security mechanisms. For those functions a
qualification of their security behavior can be made using the results of a quantitative or statistical analysis of the
security behavior of these mechanisms and the effort required to overcome them. The qualification is made in the
form of strength of TOE security function claim.

AVA_SOF.1 Strength of TOE security function evaluation

Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.1 Descriptive high-level design

Developer action elements:

AVA_SOF.1.1D The developer shall perform a strength of TOE security function analysis for each
mechanism identified in the ST as having a strength of TOE security function claim.

Content and presentation of evidence elements:

AVA_SOF.1.1C For each mechanism with a strength of TOE security function claim the strength of TOE
security function analysis shall show that it meets or exceeds the minimum strength level defined in the
PP/ST.
AVA_SOF.1.2C For each mechanism with a specific strength of TOE security function claim the strength
of TOE security function analysis shall show that it meets or exceeds the specific strength of function
metric defined in the PP/ST.

AVA_VLA.1 Developer vulnerability analysis

Vulnerability analysis is an assessment to determine whether vulnerabilities identified, during the evaluation of the
construction and anticipated operation of the TOE or by other methods (e.g. by flaw hypotheses), could allow
users to violate the TSP.
Vulnerability analysis deals with the threats that a user will be able to discover flaws that will allow unauthorized
access to resources (e.g. data), allow the ability to interfere with or alter the TSF, or interfere with the authorized
capabilities of other users.

A vulnerability analysis is performed by the developer to ascertain the presence of obvious security vulnerabilities,
and to confirm that they cannot be exploited in the intended environment for the TOE.

The evaluator should consider performing additional tests as a result of potential exploitable vulnerabilities
identified during other parts of the evaluation.

Dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.1 Descriptive high-level design
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance

Developer action elements:

AVA_VLA.1.1D The developer shall perform and document an analysis of the TOE deliverables
searching for obvious ways in which a user can violate the TSP.
AVA_VLA.1.2D The developer shall document the disposition of obvious vulnerabilities.

Content and presentation of evidence elements:

28 TeleManagement Forum 2004 TMF 053s v1.0

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

AVA_VLA.1.1C The documentation shall show, for all identified vulnerabilities, that the vulnerability cannot
be exploited in the intended environment for the TOE.

TMF 053s v1.0 TeleManagement Forum 2004 29

TM Forum NGOSS NGOSS Security Principles
Technology-Neutral Architecture

7 References

[ALSEC19] Alcatel Security Note 19, “Protecting Network Management Systems”, ALCATEL, Nov 2002

[CCISD] “Using the Common Criteria in Information System Security Design”, Proceedings of the 13th
Annual Canadian Information Technology Security Symposium, 2001

[eTOM] GB921: eTOM – the Business Process Framework, version 2.6, The TeleManagement Forum,
March 2002.

[ISO17799] ISO/IEC 17799:2000, “Information technology -- Code of practice for information security
management”, September 2001
[ISO/IEC 15408:1999] Common Criteria V. 2.1 (CC)
[SID] GB922: Shared Information/Data (SID) Model: Concepts, Principles, Business Entities, and Model
Addenda v1.5

[TMF053] TMF 053: The NGOSS™ Technology Neutral Architecture Specification. The
TeleManagement Forum, version 3.0, April 2003.

[TMF053A] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex A: Glossary. The
TeleManagement Forum, 2001.
[TMF053B] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex B: Contract
Specification. The TeleManagement Forum, 2001.
[TMF053C] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex C: Behavior and
Control Specification. The TeleManagement Forum, 2001.
[TMF053D] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex D: Metamodel
Specification. The TeleManagement Forum, 2001.
[TMF053F] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex F: Distributed
Transparency Services Specification. The TeleManagement Forum, 2001.
[TMF053M] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex M: Process
Management Specification. The TeleManagement Forum, 2001.
[TMF053N] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex N: Naming
Conventions. The TeleManagement Forum, 2001.
[TMF053P] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex P: Policy
Specification. The TeleManagement Forum, 2001.
[TMF053U] TMF 053: The NGOSS™ Technology Neutral Architecture Specification; Annex U: Use Cases.
The TeleManagement Forum, 2001.

30 TeleManagement Forum 2004 TMF 053s v1.0